Timezone (/etc/TZ) not updated correctly?

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.

Related /etc/config/system:
config system
	option ttylogin '0'
	option log_size '64'
	option urandom_seed '0'
	option log_proto 'udp'
	option conloglevel '8'
	option cronloglevel '5'
	option hostname 'R7800'
	option log_ip '192.168.1.167'
	option log_port '514'
	option zonename 'Asia/Singapore'
	option timezone '<+08>-8'

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
Related /etc/config/system:
config system
	option ttylogin '0'
	option log_size '64'
	option urandom_seed '0'
	option log_proto 'udp'
	option conloglevel '8'
	option cronloglevel '5'
	option hostname 'R7800'
	option log_ip '192.168.1.167'
	option log_port '514'
	option zonename 'Australia/Perth'
	option timezone '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

1 Like

Removed zoneinfo-asia package and now TZ file is updated correctly also for Asia/xxx Timezones.

root@R7800:~# date && cat /etc/TZ
Sun Oct 18 15:05:36 +08 2020
<+08>-8
Related /etc/config/system:
config system
	option ttylogin '0'
	option log_size '64'
	option urandom_seed '0'
	option log_proto 'udp'
	option conloglevel '8'
	option cronloglevel '5'
	option hostname 'R7800'
	option log_ip '192.168.1.167'
	option log_port '514'
	option zonename 'Asia/Singapore'
	option timezone '<+08>-8'

Seems zoneinfo packages are conflicting with LuCi inbuilt Timezone data.

1 Like

Strange.
To my knowledge, LuCI only uses the internal built-in list.

But LuCI just adjusts the config file and the main zone handling comes from musl and busybox, via that /etc/TZ or /tmp/TZ

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.

confirmed;

[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
2 Likes

LuCI only updates the /etc/config/system.
Interpreting that config is mainly handled by musl and busybox. There is also the system init script.

I doubt that LuCI plays any role here.

The integration of full zoneinfo had been last time changed in 2015

In that @hnyman linked change, the below line seem to indicate the use of zoneinfo data (assuming if present) instead of TZ and deleting the /etc/TZ.

ln -sf "/usr/share/zoneinfo/$zonename" /tmp/localtime && rm -f /tmp/TZ

I installed that zoneinfo-asia package back and indeed I have now /tmp/localtime link to correct /usr/share/zoneinfo/$zonename instead of /etc/TZ.

root@R7800:/# ls -la /tmp/localtime
lrwxrwxrwx    1 root     root            34 Oct 18 10:27 /tmp/localtime -> /usr/share/zoneinfo/Asia/Singapore

The timezone presentation though is different in /usr/share/zoneinfo/$zonename compared to /etc/TZ.

root@R7800:/# cat /usr/share/zoneinfo/Asia/Singapore
TZif2TZi ����~6S��������������gN������
�`����ʳ�`����ˑ�����Hm��a]a]bg 
                              g 
                                ix~�p�LMTSMT+07+0720+0730+09+08
<+08>-8

vs.

root@R7800:~# cat /etc/TZ
<+08>-8

Don't know whether it's chrony or other part of the system not able to update based on the /usr/share/zoneinfo/$zonename presentation of data.

Anyhow I'll remove that zoneinfo package and be with it as it is working that way.

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...

Yup, my capabilities of troubleshooting ends here and I'm ok it is woking as expected after removing zoneinfo package.

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.

one of either;

  • 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 )

  • whether you use named or offset definitions...

Looks like something has changed in the zoneinfo 2020b compilation

I compared Europe/Helsinki from 2020a and 2020b, and noticed a large size difference:
481 bytes (2020b) vs 1900 bytes (2020a).

See differences in https://github.com/openwrt/packages/pull/13644#issuecomment-712312797

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)
3 Likes

Problem was in changed default format for database.

4 Likes

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
1 Like

Version bump to 2020c has been merged to the packages repo.
It builds again the "fat" version of the zoneinfo files, so that musl is happy.

3 Likes

Thanks @hnyman and @Wedmer.

Ok after zoneinfo 2020c.
Case closed.

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).

1 Like