Noticed in recent builds the timezone is not updated correctly and /etc/TZ link is pointing to a non-existing file. The time presented by system is UTC, the one received by chrony client/server (busybox ntp client been disabled some years back and replaced with ntpd earlier and now with chrony).
root@R7800:~# date && cat /etc/TZ
Sun Oct 18 06:18:34 2020
cat: can't open '/etc/TZ': No such file or directory
I have only asian zoneinfo installed.
root@R7800:~# opkg list-installed |grep zone
zoneinfo-asia - 2020b-1
Regardless of what Timezone location I choose in LuCi/system from Asia/xxx, it will not update the TZ file.
If I choose any Timezone outside Asia/xxx, it will update TZ file correctly and adjusted time is reflected accordingly.
For example changed Timezone in LuCi/system to Australia/Perth:
root@R7800:~# date && cat /etc/TZ
Sun Oct 18 14:19:31 AWST 2020
AWST-8
Restarted box but the problem remains and above config change with issue is repeatable.
Any clue why TZ file is not updated correctly when I select Timezone from Asia/xxx ?
This problem just surfaced after sysupgrade yesterday and was working ok previously.
Current build below updated just while ago with the same problem: OpenWrt SNAPSHOT r14721+66-4ff7bdfeeb / LuCI Master git-20.280.41447-12e50de
Guessing some late changes has triggered this problem.
I've had that zoneinfo-asia package installed for the last decade and the time has been adjusted correctly.
Only yesterday spotted time was not updated correctly.
[root@dca632 /usbstick 44°]# date && cat /etc/TZ
Sun Oct 18 18:22:32 AEDT 2020
cat: can't open '/etc/TZ': No such file or directory
[root@dca632 /usbstick 44°]# date && cat /tmp/TZ
Sun Oct 18 18:23:11 AEDT 2020
cat: can't open '/tmp/TZ': No such file or directory
The full zoneinfo package has a binary database of the timezones and historical changes etc. It requires functional compatibility from the tools using it.
Completely different thing than the simple POSIX timezone string set by LuCI...
Rough overview is that the C lib is responsible for interpreting timezone and apply it to normal apps' time query functions. Musl, the default libc in OpenWrt, has been patched to accept also the /etc/TZ as a quick shortcut, as most routers do not have space for installing the full zoneinfo libs.
luci(or the underlying action of actually changing the timezone) 'use' or 'non-use' is playing a role in TZ creation... ( hence the inconsistent results )
Looks like 2020b is missing 3/4 of the earlier contents, and apparently musl needs to removed deprecated data/functionality.
EDIT:
I reverted the 2020b version bump in the packages feed.
Example of the faulty application:
Helsinki timezone gets applied ok with 2020a, while with 2020b "date" shows just GMT/UTC time:
2020b:
root at router1:~# opkg install --force-downgrade --force-reinstall
/tmp/zoneinfo-europe_2020b-1_arm_cortex-a15_neon-vfpv4.ipk
Removing package zoneinfo-europe from root...
Installing zoneinfo-europe (2020b-1) to root...
Configuring zoneinfo-europe.
root at router1:~# date
Mon Oct 19 17:50:17 2020 (--> wrong, just UTC)
2020a:
root at router1:~# opkg install --force-downgrade --force-reinstall
/tmp/zoneinfo-europe_2020a-1_arm_cortex-a15_neon-vfpv4.ipk
Removing package zoneinfo-europe from root...
Installing zoneinfo-europe (2020a-1) to root...
Configuring zoneinfo-europe.
root at router1:~# date
Mon Oct 19 20:50:25 EEST 2020 (--> correct UTC+3)
Looks ok now after handpicked @Wedmer pull request for zoneinfo 2020c.
root@R7800:/tmp# opkg list-installed |grep zone && ls -la /tmp/localtime && date && date -u && cat /etc/TZ
zoneinfo-asia - 2020c-1
lrwxrwxrwx 1 root root 34 Oct 20 13:39 /tmp/localtime -> /usr/share/zoneinfo/Asia/Singapore
Tue Oct 20 16:30:04 +08 2020
Tue Oct 20 08:30:04 UTC 2020
cat: can't open '/etc/TZ': No such file or directory
is this also explaining why i see all the times in luci with wrong time offset where i see it correct just in the system/general settings page?
with a new image build this should get fixed, right?
thanks
The problem was present in zoneinfo 2020b packages. 2020a and now 2020c should be ok.
So if you are having zoneinfo 2020b installed and using it, your description of the problem is the same I had.
LuCi front page, syslog & date command was having incorrect (UTC) clock while LuCi system/system page was showing correct local time (assuming browser time).