I raised this question here and someone said that when run on Debian, the file does get updated.
This seems to be a bug to me as the file was initially populated - where do you suggest I raise it?
`timedatectl set-timezone` doesn't update `/etc/timezone`
Well, it’s supposed to be a symlink, what exactly do you experience?
Have you tried running this command with strace to understand what’s going on in the background?
strace shows:
sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\0\1\30\0\0\0\2\0\0\0\230\0\0\0\1\1o\0\32\0\0\0/org/freedesktop/timedate1\0\0\0\0\0\0\3\1s\0\v\0\0\0SetTimezone\0\0\0\0\0\2\1s\0\31\0\0\0org.freedesk"..., iov_len=168}, {iov_base="\f\0\0\0Asia/Bangkok\0\0\0\0\1\0\0\0", iov_len=24}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 192
/etc/localtime is supposed to be a symlink.
What does your /etc/timezone point to?
That file doesn’t exist here (clean Gnome install).
From the link you posted:
/etc/timezone appears to be mostly Debian-specific (including derivatives). On Debian systems, timedatectl set-timezone also updates /etc/timezone.
What does timedatectl status say?
/etc/localtime is a symlink to the timezone stored in /usr/share/zoneinfo and should get updated when you run timedatectl set-timezone Continent/Country
This is the status in my computer:
lrwxrwxrwx 1 root root 34 Aug 16 2017 /etc/localtime -> /usr/share/zoneinfo/Asia/Jerusalem
-rw-r--r-- 1 root root 15 Aug 16 2017 /etc/timezone
Maybe you’re barking at the wrong tree? 
In old Debian (& Ubuntu) versions, there is in /etc/default/rcS/
Set UTC=no
Change it to
Set UTC=yes
Newer Debian and Ubuntu versions do not have this anymore and will follow timedatectl properly.
See this link.
ps: don’t forget to do
hwclock --systohc --utc
when time is showing correctly at panel.
Here’s my guess as to why your /etc/timezone is a 15 byte file:
% echo Asia/Jerusalem | wc -c
15
@torvic9, timedatectl status is all correct. My understanding is that it gets its Region/City from readlink on /etc/localtime.
The issue is that /etc/timezone (a different file) is not being updated by its set-timezone. It’s interesting that your setup doesn’t have this file when mine and @yaron’s does.
So, back to the original question (woof !):
Why is /etc/timezone initially poplulated but not being updated by timedatectl?
I don’t have /etc/timezone on any of my computers running a recent Manjaro.
Haven’t checked the desktop with the old install yet.
What if you delete the file?
/etc/localtime surely is enough to set the correct timezone?
Or, instead of using timedatectl, create the symlink manually?
Are you sure that /etc/timezone is even used?
Can you try and see what is the strace of timedatectl trying to fetch the current timezone?
@torvic9 Is there some specific POSIX specification for this?
Hmm… I don’t know all too much about it.
See here:
https://linux.die.net/man/3/localtime
https://linux.die.net/man/3/strftime
http://pubs.opengroup.org/onlinepubs/9699919799/functions/timezone.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/localtime.html
And more importantly, this, section “Files”:
https://linux.die.net/man/3/tzset
You can use a perl oneliner to get the timezone via strftime:
perl -MPOSIX -e 'print strftime "%Z (%z)\n",localtime' (from StackOverflow)
1 Like
Nope, this gives:
+08 (+0800)
@ yaron timedatectl gets doesn’t get it from the filesystem:
$ strace -fs300 timedatectl status |& grep Asia
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\6\1s\0\t\0\0\0:1.103827\0\0\0\0\0\0\0\10\1g\0\5a{sv}\0\0\0\0\0\0\7\1s\0\t\0\0\0:1.103825\0\0\0\0\0\0\0\300\0\0\0\0\0\0\0\10\0\0\0Timezone\0\1s\0\f\0\0\0Asia/Bangkok\0\0\0\0\0\0\0\0\10\0\0\0LocalRTC\0\1b\0\0\0\0\0\0\0\0\0\6\0\0\0CanNTP\0\1b\0\0\0\1\0\0\0\0\0\0\0\3\0\0\0NTP\0\1b\0\0\0\0\0\0\17\0\0\0NTPSynchronized\0\1b\0\0\1\0\0\0\0\0\0\0\10\0\0\0TimeUSec\0\1t\0\340w}\262\261o\5\0\v\0\0\0RTCTimeUSec\0\1t\0\0\0\0\0\0\200=}\262\261o\5\0", iov_len=264}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 264
openat(AT_FDCWD, "/usr/share/zoneinfo/Asia/Bangkok", O_RDONLY|O_CLOEXEC) = 4
write(1, " Local time: Thu 2018-06-28 18:04:38 +07\n Universal time: Thu 2018-06-28 11:04:38 UTC\n RTC time: Thu 2018-06-28 11:04:38\n Time zone: Asia/Bangkok (+07, +0700)\n System clock synchronized: yes\nsystemd-timesyncd.se"..., 354 Local time: Thu 2018-06-28 18:04:38 +07
Time zone: Asia/Bangkok (+07, +0700)
$
So something is writing /etc/timezone:
- What is it?
- Why does it write it?
Hm…here the output of the perl command and timedatectl are the same.
Tried deleting /etc/timezone?
Yes, timedatectl status didn’t change.
@yaron I can confirm that timedatectl status gets the TZ info from the symlink:
Initial status:
$ timedatectl status
Local time: Fri 2018-06-29 11:01:28 +07
Universal time: Fri 2018-06-29 04:01:28 UTC
RTC time: Fri 2018-06-29 04:01:28
Time zone: Asia/Bangkok (+07, +0700)
System clock synchronized: no
systemd-timesyncd.service active: no
RTC in local TZ: no
Overwrite symlink with contents of the file it points to:
$ sudo ln -f "$(realpath /etc/localtime)" /etc/localtime
$ timedatectl status
Local time: Fri 2018-06-29 04:04:03 UTC
Universal time: Fri 2018-06-29 04:04:03 UTC
RTC time: Fri 2018-06-29 04:04:04
Time zone: n/a (UTC, +0000)
System clock synchronized: no
systemd-timesyncd.service active: no
RTC in local TZ: no
Note the local time change to match UTC, and the n/a timezone.
So timedatectl doesn’t use /etc/timezone, but rather the /etc/localtime symlink.
So what put the file there in the first place for @yaron and myself?
I also asked What is /etc/timezone used for? on SE.Unix.
1 Like
In your Debian OS, do you have /etc/default/rcS ?
If yes, what’s in it?
I don’t have a Debian OS… Perhaps the file was carried over from somewhere?
Ok sorry, I thought you did.
Cheers.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
