I'm working on a Linux server who is in a different time zone than me. How can I make tmux display, in the status bar, my local time, instead of the server local time (without messing up the server time)? For info, I'm using tmux 3.1

In a **yocto-base Linux distribution** is available the program timedatectl and it is necessary to set the timezone. To do that exist the command:

timedatectl set-timezone

The execution of the command timedatectl list-timezones to get the list of all timezones available outputs a list empty:

> timedatectl list-timezones
UTC

The distribution doesn't include any file /usr/share/zoneinfo or /usr/zoneinfo. I think I miss installing something but I don't know what.. Thanks

On each boot into Arch, I see that the time is off by a few minutes. The RTC time is off (as far as I understood, it has "drifted".) and affects the hardware clock. $ timedatectl status Local time: Mo 2018-02-12 12:45:18 CET Universal time: Mo 2018-02-12 11:45:18 UTC RTC time: Mo 2018-02-12 11:45:18 Time zone: Europe/Berlin (CET, +0100) System clock synchronized: no systemd-timesyncd.service active: no RTC in local TZ: no **EDIT** Upon writing this post, I did not realize that the time values above this line are coherent to another. However they have an offset to my watch and smartphone time which is the aforementioned 7 minutes. And my locale: $ locale LANG=de_DE.utf8 LC_CTYPE="de_DE.utf8" LC_NUMERIC="de_DE.utf8" LC_TIME="de_DE.utf8" LC_COLLATE="de_DE.utf8" LC_MONETARY="de_DE.utf8" LC_MESSAGES="de_DE.utf8" LC_PAPER="de_DE.utf8" LC_NAME="de_DE.utf8" LC_ADDRESS="de_DE.utf8" LC_TELEPHONE="de_DE.utf8" LC_MEASUREMENT="de_DE.utf8" LC_IDENTIFICATION="de_DE.utf8" LC_ALL= So far I am very reluctant to use hwclock --hctosys as the man page states: > This function should never be used on a running system. Jumping system time will cause problems, such as corrupted filesystem timestamps. Also, if something has changed the Hardware Clock, like NTP's '11 minute mode', then --hctosys will set the time incorrectly by including drift compensation. As far as I can tell, [I configured Windows 10 correctly](https://superuser.com/questions/975717/does-windows-10-support-utc-as-bios-time) . Is there something I am missing or did I not set the clock up correctly? **EDIT 2** Upon request, the contents of /etc/ntp.conf: # Please consider joining the pool: # # http://www.pool.ntp.org/join.html # # For additional information see: # - https://wiki.archlinux.org/index.php/Network_Time_Protocol_daemon # - http://support.ntp.org/bin/view/Support/GettingStarted # - the ntp.conf man page # Associate to Arch's NTP pool server 0.arch.pool.ntp.org server 1.arch.pool.ntp.org server 2.arch.pool.ntp.org server 3.arch.pool.ntp.org # By default, the server allows: # - all queries from the local host # - only time queries from remote hosts, protected by rate limiting and kod restrict default kod limited nomodify nopeer noquery notrap restrict 127.0.0.1 restrict ::1 # Location of drift file driftfile /var/lib/ntp/ntp.drift

I always thought that the timezone is not stored by the filesystem, and that stat would show times formatted with the current timezone of the user, and therefore if I do stat on various files *today* then the timezone should not change. However this answer https://unix.stackexchange.com/questions/119323/stat-command-detail-information suggests the opposite! Different files appear with different timezones! Does anyone know why?

I've noticed that the automatic time zone detection functionality of my GNOME 3 (Arch Linux) is not working correctly. My actual time zone is PST (UTC-08), but if I toggle on the "Automatic Time Zone" option in "All Settings -> Date & Time", it would detect me to be in EST (UTC-05). Kernel: 4.9.11-1-ARCH GNOME: 3.22.3-1 Output of timedatectl: Local time: Wed 2017-03-01 05:36:18 EST Universal time: Wed 2017-03-01 10:36:18 UTC RTC time: Wed 2017-03-01 10:36:18 Time zone: America/New_York (EST, -0500) Network time on: yes NTP synchronized: yes RTC in local TZ: no Output of sudo hwclock --show: 2017-03-01 05:37:38.295861-0500 (Which is the current EST time) Output of date: Wed Mar 1 05:39:07 EST 2017 I suspected it was something wrong with my IP address, but all online IP location finder websites I've tried tell me I'm in San Francisco (which is correct). Also, I'm running dual systems (Windows 10 & Arch), and one OS writing the hardware clock always results in the other OS having an incorrect time on the next boot; I just ignore it and let the OSes' internet time services correct it. Wrong time zone detection only began today. I'm not sure how to approach this issue. Can anyone shed some light on what might be the cause?

On a host running Ubuntu 20.04 LTS I notice that, by default, journalctl (without root privileges) is the same as journalctl --utc, but with root privileges journalctl honors the time zone (as shown with timedatectl).

$ journalctl | tail -1 | tr -s ' ' | cut -d' ' -f 1-3
Sep 11 16:38:00

$ sudo journalctl | tail -1 | tr -s ' ' | cut -d' ' -f 1-3
Sep 11 13:38:13

$ timedatectl | grep "Time zone" | tr -s ' ' | cut -d' ' -f 5-6
(-03, -0300)

- I suspect Homebrew/linuxbrew is the culprit, even /home/linuxbrew/.linuxbrew/etc/systemd/journald.conf has all its line commented out, but:

$ which journalctl  # systemd 253 (253) from --version
    /home/linuxbrew/.linuxbrew/bin/journalctl
    $ sudo which journalctl  # systemd 245 (245.4-4ubuntu3.22) from --version
    /bin/journalctl

- There is no alias to journalctl What is the logic behind this behavior? How can I change that, so by default journalctl always use current system time zone?

During toolchain installation, when glibc gets installed, it reports an error message

zic: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

I checked the rpm build and installation order of the packages in the rpm list. It is like

binutils_cross gcc11_bootstrap glibc libstdc++_bootstrap binutils gcc11

After some investigation, I found that libstdc++.so.6 is installed by gcc11 rpm along with libstdc++.so.6.0.24 and libstdc++.so.6.0.24-gdb.py. And until it is glibc time for installation, libstdc++.so.6 is not in the required path. The error is reported when time zone information is compiled by 'zic' command as mentioned in the glibc spec file in the %post section after %install

zic -L /dev/null   -d $ZONEINFO       $ZONEINFO/${tz}

Query - Does zic, a timezone compiler, really require libstdc++.so.6 to compile timezone information? How can I provide the libstdc++.so.6 before the installation of gcc11 rpm? I am using Linux openSUSE Leap 42.3 Regards

Here in France, midnight 00:00 is the end of the day, in English it is the beginning of the day. In a cron table, if a batch is scheduled at 00:00 Friday, it will finish in the morning of Friday. My question is: Does changing the locale and time locale change the definition of midnight? If I configure a server with the french locale, will the batch scheduled at 00:00 Friday finish Saturday morning?

I want the just the current time in HH:MM (%R or %H:%M in strftime) in a time zone other the my system's.s Is this possible with just the date command, and if so, how?

I recently noticed the following (strange) behavior: user@pc:~$ date Mi 21. Jun 12:03:10 CEST 2017 user@pc:~$ date +%Z CEST user@pc:~$ export TZ=date +%Z user@pc:~$ date Mi 21. Jun 10:03:30 CEST 2017 user@pc:~$ date +%Z CEST Thus, after setting the TZ environment variable to the current system time zone, the clock is 2 hours delayed. It looks like UTC (CEST-2hours is UTC). If I now set TZ to other values, the clock remains unchanged: user@pc:~$ export TZ=UTC user@pc:~$ date Mi 21. Jun 10:07:09 UTC 2017 user@pc:~$ export TZ=PDT user@pc:~$ date Mi 21. Jun 10:07:19 PDT 2017 However, when I set TZ to CEST-2, it works fine again. I am a bit confused user@pc:~$ export TZ=CEST-2 user@pc:~$ date Mi 21. Jun 12:28:16 CEST 2017 I am working on xUbuntu 16.04 but this behavior is reproducible on a OpenSUSE 42.2 System. It seems to me that a time zone "ABC+X" is always considered as "UTC+X" when there is no /usr/share/zoneinfo/ABC file (thanks DevilaN for the comment). The string "ABC" is than only inserted into the date string, which is printed out. Questions: 1. Is the assumption described above correct? 2. Why does date print out a time zone abbreviation that is not supported (i.e. not available in /usr/share/zoneinfo)?

I work on a legacy system originally written in C for 3b2 SVR3, later in C++ for Sun/Solaris, now mainly for Linux. We have a few users who require our apps to run on Windows Servers, so we have accommodated that for the last 18 years using MSys / MinGW, cross compiled from our *nix-based development machines. We're now trying to upgrade to MSys 2 and have run into what appears to be an intractable problem that no amount of searching has turned up an answer to. Our application works across multiple time zones simultaneously. We can't rely on a static system time zone setting to operate properly. We get our time zone definitions from the IANA database, installed as zoneinfo files in the traditional locations, depending upon environment. We update zoneinfo for our users as the need arises. For as long as I can remember (I've worked on this for nearly 30 years), it was adequate to putenv("TZ="); tzset(); to get methods like mktime() and localtime() to produce the information we needed. That has stopped working now that we've moved to MSys 2. Additionally, most of our code doesn't care what the initial time zone is, but one method insists that the TZ variable have some value (any value, it doesn't care). It really doesn't matter why TZ must be set - that code exposes another symptom that we might not otherwise have noticed so quickly: upon entry to any of our programs, the TZ environment variable has been removed from the environment. The final curiosity is that MSys 2 comes with a **date** program that seems to work just fine with the TZ environment variable, as do **printenv** and **ls**, seeming to indicate that what we need to do *can* be done. We have a short test program we've been using to demonstrate the problem and with any luck, prove that we've found a solution: #include #include #include int main(int argc, const char *const *argv) { const char *tz = getenv("TZ"); const char *ptz = tz ? tz : "TZ not set"; printf("at entry: %s\n", ptz); time_t now = time(NULL); putenv("TZ=US/Pacific"); tzset(); printf("in %s it is now %s", getenv("TZ"), ctime(&now)); putenv("TZ=US/Eastern"); tzset(); printf("in %s it is now %s", getenv("TZ"), ctime(&now)); return 0; } When I run the above on our Linux dev machine, I get the following output: $ printenv TZ US/Central $ date "+%F %T %Z" 2024-08-15 10:20:55 CDT $ ./msystest at entry: US/Central in US/Pacific it is now Thu Aug 15 08:20:55 2024 in US/Eastern it is now Thu Aug 15 11:20:55 2024 Under MSys 2, just seconds later, I get the following: $ printenv TZ US/Central $ date "+%F %T %Z" 2024-08-15 10:20:57 CDT $ ./msystest at entry: TZ not set in US/Pacific it is now Thu Aug 15 16:20:57 2024 in US/Eastern it is now Thu Aug 15 16:20:57 2024 Using **ldd** on MSys 2, we've noticed that there are different DLLs referenced by **date** and **msystest**: $ ldd /usr/bin/date ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ff962d20000) KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ff961b30000) KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ff960340000) msys-intl-8.dll => /usr/bin/msys-intl-8.dll (0x430b30000) msys-2.0.dll => /usr/bin/msys-2.0.dll (0x180040000) msys-iconv-2.dll => /usr/bin/msys-iconv-2.dll (0x5603f0000) $ ldd msystest ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ff962d20000) KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ff961b30000) KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ff960340000) msvcrt.dll => /c/Windows/System32/msvcrt.dll (0x7ff962790000) So our question is - is our problem the result of the differing DLLs, and if so, how do we get the msys DLLs built into our programs rather than the msvcrt DLL? We've done a lot of searching online to try to resolve this to little avail. We usually get 1 of 2 answers: 1. Windows doesn't work that way so you can't do what you want with MSys 2. This is how you build a DLL with MinGW Needless to say, the answers are either (1) wrong, or (2) answering the wrong question. Any help anyone can provide/point us to would be invaluable.

I need the time to lag exactly by 1 second. That is, so that the time is synchronized, but lags. Now I use timedatectl set-ntp on. How can this be achieved? Maybe there is a possibility to set the time zone to -1sec?

In this answer , Stéphane Chazelas uses a UVC timezone and vs_VS locale. When I asked about them, the reply was that these are the timezone and locale used on ... Venus. I'm not entirely sure whether the response was tongue-in-cheek, and it might well be something bespoke. But I'm interested in trying out these settings, so I how can I do that on Arch Linux or a recent Ubuntu release, without having a friend from Venus?

I have an EC2 instance that runs linux. The timezone is set to UTC time and I need my cron tasks to work on UK timezone. However, I am unable to change the system clock to the UK timezone. It must remain in UTC. I know I can use CRON_TZ=Europe/London, yet when I do so my command below will not run on the UK timezone. Only UTC. CRON_TZ=Europe/London 10 15 * * * echo "$(date) This is UTC time!" > /tmp/utc.txt 10 15 * * * TZ=Europe/London echo "$(date) This is Europe/London time!" > /tmp/london2.txt This occurs even if I put the timezone in the command line instead of at the top of the crontab file. I have restarted the cron server. I have edited the crontab file from root and from a specific user. I have even added the cron_tz variable at the start of each command. As shown below. Nothing is making cron trigger at the UK time. * * * * * TZ=Europe/London echo "$(date) This is Europe/London time!" > /tmp/london2.txt The only way to fix this is this: UK time is 1 hour ahead of UTC time. When I change the system clock to November, the clocks in the UK go back 1 hour and are then equal to UTC time. This is the only time cron will run at the right time. Is there any way to make cron trigger at the UK time without having to worry about the clocks going forwards or back?

I always thought Linux systems used */etc/timezone* for the timezone, but:

$ cat /etc/timezone 
Etc/UTC
$ date
Tue May 28 12:34:01 PM PDT 2024

Here, the */etc/timezone* is UTC but date is reporting in PDT. How is date determining the timezone? This is Ubuntu 22.04, if it matters.

I dual booted my laptop and installed EndeavourOS (while other OS being windows 10) Due to this, my hardware and system clock both show the wrong time. I have set the correct time zone (UTC+5:30), still it shows the wrong time. timedatctl Local time: Sat 2023-02-25 09:12:46 IST Universal time: Sat 2023-02-25 03:42:46 UTC RTC time: Sat 2023-02-25 03:42:46 Time zone: Asia/Kolkata (IST, +0530) System clock synchronized: no NTP service: active RTC in local TZ: no This is the snap of my terminal which is showing the wrong time even the UTC time which is around 3:59 and the local time here is 9:29 at the moment of writing this post. I have looked at various sites, but couldn't find a fix for this. Any help would be appreciated!

I'm facing challenges in implementing a cron job for our daily check-in feature. Our goal is to send a push notification alarm daily to remind users to check in if they haven't already. The timing of these alarms should follow each user's local time zone. For example, Korean users should receive the push notification at 5 PM Korean time, while American users should receive it at 5 PM in their local (American) time zone. How can I achieve this?? I've already implemented the business logic. It checks whether a user is targeted or not and sends the push alarm accordingly. Is it possible to control the cron job time based on the user's time zone, or should I consider modifications at the user business logic level? As a beginner developer, I apologize if I didn't provide enough information in my question.  Please leave your comments, and I'll try to rewrite it.

I have a 3rd-party SFTP server on which I want to check some file timestamps. However, I do get different results for the same file if I use ls -l vs. ls -lh:

sftp> ls -l
[...]
-rwxrwxrwx 1 0        0               1963 Nov 15 08:49 foo.txt
[...]

sftp> ls -lh
[...]
-rwxrwxrwx    0 0        0            1.9K Nov 15 07:49 foo.txt
[...]

sftp> ls -l foo.txt
-rwxrwxrwx    0 0        0            1963 Nov 15 07:49 foo.txt

sftp> ls -lh foo.txt
-rwxrwxrwx    0 0        0            1.9K Nov 15 07:49 foo.txt

As you can see, the timestamp in ls -l is 08:49 whereas the other commands have 07:49. The server is in Germany which currently is 1h later than UTC, so my guess is that 07:49 is UTC whereas 08:49 is Berlin time. However, my machine is on UTC:

$ cat /etc/timezone 
Etc/UTC

My understanding is that, according to the SFTP standard, all timestamps should be in UTC. However I'm not sure whether that understanding is correct (given that there are so many different versions of the standard). I also don't know whether the sftp tool somehow postprocesses the timestamps (man sftp doesn't mention timezones or timestamps at all). What could be the reason for the difference?

I expected that timedatectl would update /etc/timezone when changing timezones, but no: % sudo timedatectl set-timezone 'Asia/Kuala_Lumpur' % cat /etc/timezone Asia/Bangkok Is there a reason that it doesn't? (Bug?) If I manually update /etc/timezone to match timedatectl set-timezone, are there any side-effects I should be aware of? Is there anywhere else I should consider changing timezone, eg [xfce4 panel clock](https://unix.stackexchange.com/a/227405/143394) ?

I am working with an embedded Linux (ARM/busybox) system. It has systemd and the timedatectl system executable, but it does not have /etc/timezone, /usr/share/zoneinfo, nor the zic timezone data compiler program. I have plenty of system diskspace on this embedded system. Is it possible to copy the /usr/share/zoneinfo contents from an amd64 Linux implementation to my embedded ARM Linux implementation "as-is" to get access to the timezone functionality that timedatectl provides? Thanks for your help.