Troubles with zone Asia/Gaza after tzdata2020b release
Dear tzdata maintainers, I have found that after tzdata2020b release something has gone wrong with Asia/Gaza timezone, which is related to Palestine. For checking I used this information https://www.timeanddate.com/worldclock/palestine/gaza and for DST at 2019: https://www.timeanddate.com/time/change/palestine/gaza?year=2019 for DST at 2020: https://www.timeanddate.com/time/change/palestine/gaza?year=2020 for DST at 2021: https://www.timeanddate.com/time/change/palestine/gaza?year=2021 I compiled all last release of tzdata from 2019c to 2021a and was comparing them with Ubuntu packages for 2020b on groovy (20.10) and 2021a on bionic (18.04). If several changes in the date of DST for different years can be related with last applied laws of DST in Palestine (described here http://mm.icann.org/pipermail/tz/2020-October/029376.html), but broken timezone output in letters or numbers is speaking about any error in the this time zone code. Can you investigate this too ? On screenshot you can see all my investigation: [cid:image002.png@01D70EDB.BE0D5350] Also I share all commands and listing for your execution itself: [root@Router8:~]# ls -la /etc/localtime lrwxrwxrwx 1 root root 35 Mar 4 2021 /etc/localtime -> /usr/share/zoneinfo/posix/Asia/Gaza [root@Router8:~]# ls -la /usr/share/zoneinfo/posix/Asia/Gaza* lrwxrwxrwx 1 root root 41 Mar 27 01:00 /usr/share/zoneinfo/posix/Asia/Gaza -> /usr/share/zoneinfo/posix/Asia/Gaza.2019c -rw-r--r-- 1 root root 2316 Oct 22 09:34 /usr/share/zoneinfo/posix/Asia/Gaza.2019c -rw-r--r-- 1 root root 2316 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020a -rw-r--r-- 1 root root 1166 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020b -rw-r--r-- 1 root root 1166 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020c -rw-r--r-- 1 root root 1195 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020d -rw-r--r-- 1 root root 1213 Mar 1 2021 /usr/share/zoneinfo/posix/Asia/Gaza.2021a -rw-r--r-- 1 root root 2316 Oct 19 2020 /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b -rw-r--r-- 1 root root 2459 Jan 27 2021 /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a [root@Router8:~]# date +"%Y%m%d %T" -s "20190328 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20190328 23:59:55 Thu Mar 28 23:59:59 2019 +0200 EET Fri Mar 29 01:00:01 2019 +0300 EEST [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020a /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020a' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0200 EET Fri Mar 27 01:00:01 2020 +0300 EEST [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020b /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020b' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0000 Fri Mar 27 00:00:01 2020 +0000 [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020c /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020c' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0000 Fri Mar 27 00:00:01 2020 +0000 [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0200 EET Fri Mar 27 01:00:01 2020 +0300 EEST [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2021a /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2021a' [root@Router8:~]# date +"%Y%m%d %T" -s "20210326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20210326 23:59:55 Fri Mar 26 23:59:59 2021 +0000 Sat Mar 27 00:00:01 2021 +0000 [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a' [root@Router8:~]# date +"%Y%m%d %T" -s "20210326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20210326 23:59:55 Fri Mar 26 23:59:59 2021 +0200 EET Sat Mar 27 01:00:01 2021 +0300 EEST Best regards, [cid:image001.jpg@01D70EC7.959CF010] Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com/>
Evgheni, The first thing I noticed was the disparate file sizes that all of your compiled Asia/Gaza.* files have. It looks like all of the larger (~2.3 kB) files are yielding the correct/expected results (EET and EEST), while the smaller (~1.2 kB) files are not. I suspect that, in the cases of the smaller files, there is likely no real data in the v1 data block, which is to say that the first 51 bytes would look something like this: $ hexdump -n51 -C Asia/Gaza 00000000 54 5a 69 66 33 00 00 00 00 00 00 00 00 00 00 00 |TZif3...........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 00 |................| 00000030 00 00 00 |...| 00000033 For such files, the useful data, so to speak, is in the version 2+ data block which begins directly after these bytes. (The format of these data blocks are described in detail in §3.2 of RFC8536.) https://www.rfc-editor.org/rfc/rfc8536.html#section-3.2 The next thing I recalled is that, beginning with version 2020b, our packaged version of zic now defaults to using the "-b slim" option which removes the v1 data block in this way, since it is dependent on 32-bit timestamps that will rollover in early 2038 and is thus decreasing in utility as that date nears. https://github.com/eggert/tz/commit/6ba6f2117b95eab345a7ed9159cef939e30c4cd3 https://mm.icann.org/pipermail/tz/2020-June/029125.html It seems that, for now, the Ubuntu maintainers have decided to still compile with "-b fat" to maintain the v1 data block, which is why their files seem to work for you. So this brings us the logical follow-on question: Why is the system you're testing only looking at the (legacy) 32-bit data in the v1 data block, and not using the 64-bit data in the v2+ data block? Please let us know more about the system you're running so that we can get a better sense of which platforms have successfully made the transition to properly using TZif version 2+ data for 64-bit timestamps, and which haven't. -- Tim Parenti On Mon, 1 Mar 2021 at 14:19, Evgheni Antropov via tz <tz@iana.org> wrote:
Dear tzdata maintainers,
I have found that after tzdata2020b release something has gone wrong with Asia/Gaza timezone, which is related to Palestine.
For checking I used this information https://www.timeanddate.com/worldclock/palestine/gaza and
for DST at 2019: https://www.timeanddate.com/time/change/palestine/gaza?year=2019
for DST at 2020: https://www.timeanddate.com/time/change/palestine/gaza?year=2020
for DST at 2021: https://www.timeanddate.com/time/change/palestine/gaza?year=2021
I compiled all last release of tzdata from 2019c to 2021a and was comparing them with Ubuntu packages for 2020b on groovy (20.10) and 2021a on bionic (18.04).
If several changes in the date of DST for different years can be related with last applied laws of DST in Palestine (described here http://mm.icann.org/pipermail/tz/2020-October/029376.html), but broken timezone output in letters or numbers is speaking about any error in the this time zone code.
Can you investigate this too ?
On screenshot you can see all my investigation:
Also I share all commands and listing for your execution itself:
[root@Router8:~]# ls -la /etc/localtime
lrwxrwxrwx 1 root root 35 Mar 4 2021 /etc/localtime -> /usr/share/zoneinfo/posix/Asia/Gaza
[root@Router8:~]# ls -la /usr/share/zoneinfo/posix/Asia/Gaza*
lrwxrwxrwx 1 root root 41 Mar 27 01:00 /usr/share/zoneinfo/posix/Asia/Gaza -> /usr/share/zoneinfo/posix/Asia/Gaza.2019c
-rw-r--r-- 1 root root 2316 Oct 22 09:34 /usr/share/zoneinfo/posix/Asia/Gaza.2019c
-rw-r--r-- 1 root root 2316 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020a
-rw-r--r-- 1 root root 1166 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020b
-rw-r--r-- 1 root root 1166 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020c
-rw-r--r-- 1 root root 1195 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020d
-rw-r--r-- 1 root root 1213 Mar 1 2021 /usr/share/zoneinfo/posix/Asia/Gaza.2021a
-rw-r--r-- 1 root root 2316 Oct 19 2020 /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b
-rw-r--r-- 1 root root 2459 Jan 27 2021 /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a
[root@Router8:~]# date +"%Y%m%d %T" -s "20190328 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z
20190328 23:59:55
Thu Mar 28 23:59:59 2019 +0200 EET
Fri Mar 29 01:00:01 2019 +0300 EEST
[root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020a /usr/share/zoneinfo/posix/Asia/Gaza
'/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020a'
[root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z
20200326 23:59:55
Thu Mar 26 23:59:59 2020 +0200 EET
Fri Mar 27 01:00:01 2020 +0300 EEST
[root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020b /usr/share/zoneinfo/posix/Asia/Gaza
'/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020b'
[root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z
20200326 23:59:55
Thu Mar 26 23:59:59 2020 +0000
Fri Mar 27 00:00:01 2020 +0000
[root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020c /usr/share/zoneinfo/posix/Asia/Gaza
'/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020c'
[root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z
20200326 23:59:55
Thu Mar 26 23:59:59 2020 +0000
Fri Mar 27 00:00:01 2020 +0000
[root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b /usr/share/zoneinfo/posix/Asia/Gaza
'/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b'
[root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z
20200326 23:59:55
Thu Mar 26 23:59:59 2020 +0200 EET
Fri Mar 27 01:00:01 2020 +0300 EEST
[root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2021a /usr/share/zoneinfo/posix/Asia/Gaza
'/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2021a'
[root@Router8:~]# date +"%Y%m%d %T" -s "20210326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z
20210326 23:59:55
Fri Mar 26 23:59:59 2021 +0000
Sat Mar 27 00:00:01 2021 +0000
[root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a /usr/share/zoneinfo/posix/Asia/Gaza
'/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a'
[root@Router8:~]# date +"%Y%m%d %T" -s "20210326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z
20210326 23:59:55
Fri Mar 26 23:59:59 2021 +0200 EET
Sat Mar 27 01:00:01 2021 +0300 EEST
Best regards,
Evgheni Antropov
Software R&D Engineer
+373 22 404 665
www.addgrup.com
On 3/1/21 1:19 PM, Tim Parenti via tz wrote:
Why is the system you're testing only looking at the (legacy) 32-bit data in the v1 data block, and not using the 64-bit data in the v2+ data block? Please let us know more about the system you're running
Another possibility is that Evgheni is using a stripped down library that ignores both data blocks, and uses only the TZ string at the end. Such a library does not conform to Internet RFC 8536 but might be suitable for stripped down devices such as a router. For Asia/Gaza, the TZ string is TZ='EET-2EEST,M3.4.4/48,M10.4.4/49', where the "48" and "49" rely on the extension specified in Internet RFC 8536 section 3.3.1 and scheduled to appear in a future POSIX release. If Evgheni's library doesn't support that extension then that's the problem. Yet another possibility is that Evgheni's library simply ignores the TZ string. '-b slim' relies on the TZ string even for current timestamps, whereas '-b fat' fills out entries through 2038. However, if this were the issue I expect it would happen for timezones other than Asia/Gaza.
Please let us know more about the system you're running
Yes, that'd be helpful.
Dear Paul and Tim, Thank you for attention to this issue. We're using tzdata on the our embedded devices with ARMv7 Processor rev 2 (v7l), which has vanilla kernel [root@Router8:~]# uname -a Linux Router8 4.4.19-gdb0b54cdad #49 PREEMPT Mon Sep 30 15:10:54 EEST 2019 armv7l GNU/Linux Whole filesystem was compiled using Yocto Project 1.5 (poky-dora-10.0.0) https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora Tzdata was compiling on Ubuntu 18.04 without any additional flags and cross-compilers, just simple make install #!/bin/sh make clean #For compiling source extract tzdata and tzcode in one directory and run: make TOPDIR=$(pwd)/binaries install with additional changes related with requests from our several customers, which are not effecting on the this file. In attachment you can see whole listing of compilation. Best regards, Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com> -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Tuesday, March 2, 2021 01:59 To: Tim Parenti <tim@timtimeonline.com> Cc: Evgheni Antropov <Evgheni.Antropov@addgrup.com>; Time zone mailing list <tz@iana.org> Subject: Re: [tz] Troubles with zone Asia/Gaza after tzdata2020b release On 3/1/21 1:19 PM, Tim Parenti via tz wrote:
Why is the system you're testing only looking at the (legacy) 32-bit data in the v1 data block, and not using the 64-bit data in the v2+ data block? Please let us know more about the system you're running
Another possibility is that Evgheni is using a stripped down library that ignores both data blocks, and uses only the TZ string at the end. Such a library does not conform to Internet RFC 8536 but might be suitable for stripped down devices such as a router. For Asia/Gaza, the TZ string is TZ='EET-2EEST,M3.4.4/48,M10.4.4/49', where the "48" and "49" rely on the extension specified in Internet RFC 8536 section 3.3.1 and scheduled to appear in a future POSIX release. If Evgheni's library doesn't support that extension then that's the problem. Yet another possibility is that Evgheni's library simply ignores the TZ string. '-b slim' relies on the TZ string even for current timestamps, whereas '-b fat' fills out entries through 2038. However, if this were the issue I expect it would happen for timezones other than Asia/Gaza.
Please let us know more about the system you're running
Yes, that'd be helpful.
On 2021-03-02 01:49, Evgheni Antropov via tz wrote:
On Tuesday, March 2, 2021 01:59, Paul Eggert wrote:
On 3/1/21 1:19 PM, Tim Parenti via tz wrote:
Another possibility is that Evgheni is using a stripped down library that ignores both data blocks, and uses only the TZ string at the end. Such a library does not conform to Internet RFC 8536 but might be suitable for stripped down devices such as a router. For Asia/Gaza, the TZ string is TZ='EET-2EEST,M3.4.4/48,M10.4.4/49', where the "48" and "49" rely on the extension specified in Internet RFC 8536 section 3.3.1 and scheduled to appear in a future POSIX release. If Evgheni's library doesn't support that extension then that's the problem.
Yet another possibility is that Evgheni's library simply ignores the TZ string. '-b slim' relies on the TZ string even for current timestamps, whereas '-b fat' fills out entries through 2038. However, if this were the issue I expect it would happen for timezones other than Asia/Gaza.
Why is the system you're testing only looking at the (legacy) 32-bit data in the v1 data block, and not using the 64-bit data in the v2+ data block? Please let us know more about the system you're running
Please let us know more about the system you're running
Yes, that'd be helpful.
Thank you for attention to this issue.
We're using tzdata on the our embedded devices with ARMv7 Processor rev 2 (v7l), which has vanilla kernel [root@Router8:~]# uname -a Linux Router8 4.4.19-gdb0b54cdad #49 PREEMPT Mon Sep 30 15:10:54 EEST 2019 armv7l GNU/Linux
Whole filesystem was compiled using Yocto Project 1.5 (poky-dora-10.0.0) https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora <https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora>
Tzdata was compiling on Ubuntu 18.04 without any additional flags and cross-compilers, just simple make install
#!/bin/sh make clean #For compiling source extract tzdata and tzcode in one directory and run: make TOPDIR=$(pwd)/binaries install
with additional changes related with requests from our several customers, which are not effecting on the this file. > In attachment you can see whole listing of compilation.
This may be less useful than knowing what libc code is being used on tzdata. The Yocto/OpenEmbedded project seems to be a system for managing recipes to apply thousands of patches to upstream components and tools on multiple host platforms. It appears from yocto docs and links, that depending on the yocto version, it may be based on OpenEmbedded with some earlier trimmed embedded version of glibc (perhaps 2.24 as of yocto 2.2) or musl (version?) libc, which may not have tzcode changes merged to handle current tzdata formats. Traditionally glibc/libc... use requires libc-bin which packages utilities including zic, zdump built using system libc conventions and structures. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Dear Brian, We're using following version of glibc on the our Embedded devices: [root@Router8:~]# ldd --version ldd (EGLIBC) 2.18 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. [root@Router8:~]# ldd /lib/libc-2.18.so /lib/ld-linux.so.3 (0xb6fa0000) Compiled by GNU CC version 4.8.1. Compiled on a Linux 3.10.0 system on 2013-11-14. Based on the strings output it is supporting this bunch of versions: GLIBC_2.4 GLIBC_2.5 GLIBC_2.6 GLIBC_2.7 GLIBC_2.8 GLIBC_2.9 GLIBC_2.10 GLIBC_2.11 GLIBC_2.12 GLIBC_2.13 GLIBC_2.14 GLIBC_2.15 GLIBC_2.16 GLIBC_2.17 GLIBC_2.18 GLIBC_PRIVATE Also I found this structure in the strings of glibc, which perhaps describe TZif or something related with tz files __extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p (&zone_names[info->idx]) && __builtin_constant_p (__tzname[tp->tm_isdst]) && (__s1_len = strlen (&zone_names[info->idx]), __s2_len = strlen (__tzname[tp->tm_isdst]), (!((size_t)(const void *)((&zone_names[info->idx]) + 1) - (size_t)(const void *)(&zone_names[info->idx]) == 1) || __s1_len >= 4) && (!((size_t)(const void *)((__tzname[tp->tm_isdst]) + 1) - (size_t)(const void *)(__tzname[tp->tm_isdst]) == 1) || __s2_len >= 4)) ? __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst]) : (__builtin_constant_p (&zone_names[info->idx]) && ((size_t)(const void *)((&zone_names[info->idx]) + 1) - (size_t)(const void *)(&zone_names[info->idx]) == 1) && (__s1_len = strlen (&zone_names[info->idx]), __s1_len < 4) ? (__builtin_constant_p (__tzname[tp->tm_isdst]) && ((size_t)(const void *)((__tzname[tp->tm_isdst]) + 1) - (size_t)(const void *)(__tzname[tp->tm_isdst]) == 1) ? __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst]) : (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (__tzname[tp->tm_isdst]); int __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[0] - __s2[0]); if (__s1_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[1] - __s2[1]); if (__s1_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[2] - __s2[2]); if (__s1_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[3] - __s2[3]); } } __result; }))) : (__builtin_constant_p (__tzname[tp->tm_isdst]) && ((size_t)(const void *)((__tzname[tp->tm_isdst]) + 1) - (size_t)(const void *)(__tzname[tp->tm_isdst]) == 1) && (__s2_len = strlen (__tzname[tp->tm_isdst]), __s2_len < 4) ? (__builtin_constant_p (&zone_names[info->idx]) && ((size_t)(const void *)((&zone_names[info->idx]) + 1) - (size_t)(const void *)(&zone_names[info->idx]) == 1) ? __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst]) : (- (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (&zone_names[info->idx]); int __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[0] - __s2[0]); if (__s2_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[1] - __s2[1]); if (__s2_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[2] - __s2[2]); if (__s2_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[3] - __s2[3]); } } __result; })))) : __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst])))); }) == 0 From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca<mailto:Brian.Inglis@SystematicSw.ab.ca>> Sent: Tue, 2 Mar 2021 09:55:51 -0700 To: Evgheni Antropov Cc: Time zone mailing list <tz@iana.org> Subject: RE: [tz] Troubles with zone Asia/Gaza after tzdata2020b release This may be less useful than knowing what libc code is being used on tzdata. The Yocto/OpenEmbedded project seems to be a system for managing recipes to apply thousands of patches to upstream components and tools on multiple host platforms. It appears from yocto docs and links, that depending on the yocto version, it may be based on OpenEmbedded with some earlier trimmed embedded version of glibc (perhaps 2.24 as of yocto 2.2) or musl (version?) libc, which may not have tzcode changes merged to handle current tzdata formats. Traditionally glibc/libc... use requires libc-bin which packages utilities including zic, zdump built using system libc conventions and structures. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] Best regards, [cid:image001.jpg@01D7101A.B72A3630] Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com/> From: Evgheni Antropov Sent: Tuesday, March 2, 2021 10:50 To: 'Paul Eggert' <eggert@cs.ucla.edu>; Tim Parenti <tim@timtimeonline.com> Cc: Time zone mailing list <tz@iana.org> Subject: RE: [tz] Troubles with zone Asia/Gaza after tzdata2020b release Dear Paul and Tim, Thank you for attention to this issue. We're using tzdata on the our embedded devices with ARMv7 Processor rev 2 (v7l), which has vanilla kernel [root@Router8:~]# uname -a Linux Router8 4.4.19-gdb0b54cdad #49 PREEMPT Mon Sep 30 15:10:54 EEST 2019 armv7l GNU/Linux Whole filesystem was compiled using Yocto Project 1.5 (poky-dora-10.0.0) https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora Tzdata was compiling on Ubuntu 18.04 without any additional flags and cross-compilers, just simple make install #!/bin/sh make clean #For compiling source extract tzdata and tzcode in one directory and run: make TOPDIR=$(pwd)/binaries install with additional changes related with requests from our several customers, which are not effecting on the this file. In attachment you can see whole listing of compilation. Best regards, Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com> -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu<mailto:eggert@cs.ucla.edu>> Sent: Tuesday, March 2, 2021 01:59 To: Tim Parenti <tim@timtimeonline.com<mailto:tim@timtimeonline.com>> Cc: Evgheni Antropov <Evgheni.Antropov@addgrup.com<mailto:Evgheni.Antropov@addgrup.com>>; Time zone mailing list <tz@iana.org<mailto:tz@iana.org>> Subject: Re: [tz] Troubles with zone Asia/Gaza after tzdata2020b release On 3/1/21 1:19 PM, Tim Parenti via tz wrote:
Why is the system you're testing only looking at the (legacy) 32-bit data in the v1 data block, and not using the 64-bit data in the v2+ data block? Please let us know more about the system you're running
Another possibility is that Evgheni is using a stripped down library that ignores both data blocks, and uses only the TZ string at the end. Such a library does not conform to Internet RFC 8536 but might be suitable for stripped down devices such as a router. For Asia/Gaza, the TZ string is TZ='EET-2EEST,M3.4.4/48,M10.4.4/49', where the "48" and "49" rely on the extension specified in Internet RFC 8536 section 3.3.1 and scheduled to appear in a future POSIX release. If Evgheni's library doesn't support that extension then that's the problem. Yet another possibility is that Evgheni's library simply ignores the TZ string. '-b slim' relies on the TZ string even for current timestamps, whereas '-b fat' fills out entries through 2038. However, if this were the issue I expect it would happen for timezones other than Asia/Gaza.
Please let us know more about the system you're running
Yes, that'd be helpful.
On 2021-03-03 03:25, Evgheni Antropov wrote:
On Tue, 2 Mar 2021 09:55:51 -0700, Brian Inglis wrote:
On 2021-03-02 01:49, Evgheni Antropov wrote:
On Tuesday, March 2, 2021 01:59, Paul Eggert wrote:
On 3/1/21 1:19 PM, Tim Parenti wrote: Another possibility is that Evgheni is using a stripped down library that ignores both data blocks, and uses only the TZ string at the end. Such a library does not conform to Internet RFC 8536 but might be suitable for stripped down devices such as a router. For Asia/Gaza, the TZ string is TZ='EET-2EEST,M3.4.4/48,M10.4.4/49', where the "48" and "49" rely on the extension specified in Internet RFC 8536 section 3.3.1 and scheduled to appear in a future POSIX release. If Evgheni's library doesn't support that extension then that's the problem.
Yet another possibility is that Evgheni's library simply ignores the TZ string. '-b slim' relies on the TZ string even for current timestamps, whereas '-b fat' fills out entries through 2038. However, if this were the issue I expect it would happen for timezones other than Asia/Gaza.
Why is the system you're testing only looking at the (legacy) 32-bit data in the v1 data block, and not using the 64-bit data in the v2+ data block? Please let us know more about the system you're running
Yes, that'd be helpful.
Thank you for attention to this issue. We're using tzdata on the our embedded devices with ARMv7 Processor rev 2 (v7l), which has vanilla kernel [root@Router8:~]# uname -a Linux Router8 4.4.19-gdb0b54cdad #49 PREEMPT Mon Sep 30 15:10:54 EEST 2019 armv7l GNU/Linux
Whole filesystem was compiled using Yocto Project 1.5 (poky-dora-10.0.0) https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora <https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora>
Tzdata was compiling on Ubuntu 18.04 without any additional flags and cross-compilers, just simple make install
#!/bin/sh make clean #For compiling source extract tzdata and tzcode in one directory and run: make TOPDIR=$(pwd)/binaries install
with additional changes related with requests from our several customers, which are not effecting on the this file. In attachment you can see whole listing of compilation.
This may be less useful than knowing what libc code is being used on tzdata.
The Yocto/OpenEmbedded project seems to be a system for managing recipes to apply thousands of patches to upstream components and tools on multiple host platforms.
It appears from yocto docs and links, that depending on the yocto version, it may be based on OpenEmbedded with some earlier trimmed embedded version of glibc (perhaps 2.24 as of yocto 2.2) or musl (version?) libc, which may not have tzcode changes merged to handle current tzdata formats.
Traditionally glibc/libc... use requires libc-bin which packages utilities including zic, zdump built using system libc conventions and structures.
We’re using following version of glibc on the our Embedded devices: [root@Router8:~]# ldd --version ldd (EGLIBC) 2.18 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. [root@Router8:~]# ldd /lib/libc-2.18.so /lib/ld-linux.so.3 (0xb6fa0000) Compiled by GNU CC version 4.8.1. Compiled on a Linux 3.10.0 system on 2013-11-14. Based on the strings output it is supporting this bunch of versions: ... GLIBC_2.18 GLIBC_PRIVATE ...
The strings don't tell us anything about what your 2013 eglibc (unsupported and abandoned in 2014 to return to glibc) supports in the way of tz data content and features, as the instructions you use (which may not be accurate for your library or current tz code or data) assume that you are running a current Yocto/OpenEmbedded/glibc release, not an 8 year old orphaned library that may be extensively patched in many ways. As with any code base left to linger for years without resyncing to upstream sources, you will have to do software archaeology on the time function sources, compare to glibc and/or tzcode from that era, figure out whether and what to patch, and what data needs generated by zic that it can support. Your best option may be following suggestions to generate data using e.g.: $ zic -b slim -r @0/@2147483647 <data files> or the make equivalent to exclude leapseconds, right and posix, backward, backzone, and legacy files, and include data only until 2038, unless you really need some of those extra features or time range, in which case you will need to update your library functions. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
On 3/3/21 8:06 AM, Brian Inglis via tz wrote:
Your best option may be following suggestions to generate data using e.g.:
$ zic -b slim -r @0/@2147483647 <data files>
or the make equivalent to exclude leapseconds, right and posix, backward, backzone, and legacy files, and include data only until 2038, unless you really need some of those extra features or time range, in which case you will need to update your library functions.
I'd also suggest trying "-b fat" instead of "-b slim". But at any rate, if you're using a library that old and unsupported I have my doubts as to whether your devices will keep working after the year 2038, no matter what zic options you use.
Dear Brian and Paul, Thank you for suggestion and dreads about our future troubles with tzdata. Our Hardware Release cycle is around 10 years and of course we will change version of (e)glibc as it will be possible, but precise till to 2038. I tried to execute zic command with suggested options on the host machine (Ubuntu 18.04), where I compiled tzdata/tzcode 2021a. It showed those errors (I attached and trace output from strace). May be I need to compile zic with my embedded cross-compiler and run it direct on the embedded device, where is placed obsolete eglibc for correct result ? ⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -b slim -r @0/@2147483647 Gaza "Gaza", line 1: line too long ⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -b fat -r @0/@2147483647 Gaza "Gaza", line 1: line too long ⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -v -b fat -r @0/@2147483647 Gaza "Gaza", line 1: line too long ⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic --help /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic: usage is /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic [ --version ] [ --help ] [ -v ] \ [ -b {slim|fat} ] [ -d directory ] [ -l localtime ] [ -L leapseconds ] \ [ -p posixrules ] [ -r '[@lo][/@hi]' ] [ -t localtime-link ] \ [ filename ... ] Report bugs to tz@iana.org. ⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -v -b fat -r @0/@2147483647 -d /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/share/zoneinfo/Asia Gaza "Gaza", line 1: line too long ⋊> /h/R/p/t/t/t/b/u/s/z/Asia strace /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -v -b fat -r @0/@2147483647 -d /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/share/zoneinfo/Asia Gaza execve("/home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic", ["/home/RTR8A/projects/tzdata/tzda"..., "-v", "-b", "fat", "-r", "@0/@2147483647", "-d", "/home/RTR8A/projects/tzdata/tzda"..., "Gaza"], 0xbfd09290 /* 19 vars */) = 0 brk(NULL) = 0x884000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f74000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=87711, ...}) = 0 mmap2(NULL, 87711, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f5e000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\220\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1942936, ...}) = 0 mmap2(NULL, 1948192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d82000 mprotect(0xb7f57000, 4096, PROT_NONE) = 0 mmap2(0xb7f58000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d5000) = 0xb7f58000 mmap2(0xb7f5b000, 10784, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f5b000 close(3) = 0 set_thread_area({entry_number=-1, base_addr=0xb7f75100, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=6) mprotect(0xb7f58000, 8192, PROT_READ) = 0 mprotect(0x447000, 4096, PROT_READ) = 0 mprotect(0xb7fa0000, 4096, PROT_READ) = 0 munmap(0xb7f5e000, 87711) = 0 umask(022) = 022 umask(022) = 022 brk(NULL) = 0x884000 brk(0x8a5000) = 0x8a5000 brk(0x8a6000) = 0x8a6000 openat(AT_FDCWD, "Gaza", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1213, ...}) = 0 read(3, "TZif3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 1213 write(2, "\"Gaza\", line 1: ", 16"Gaza", line 1: ) = 16 write(2, "line too long", 13line too long) = 13 write(2, "\n", 1 ) = 1 _llseek(3, -809, [404], SEEK_CUR) = 0 exit_group(1) = ? +++ exited with 1 +++
Your best option may be following suggestions to generate data using e.g.:
$ zic -b slim -r @0/@2147483647 <data files>
or the make equivalent to exclude leapseconds, right and posix, backward, backzone, and legacy files, and include data only until 2038, unless you really need some of those extra features or time range, in which case you will need to update your library functions.
I'd also suggest trying "-b fat" instead of "-b slim". But at any rate, if you're using a library that old and unsupported I have my doubts as to whether your devices will keep working after the year 2038, no matter what zic options you use.
Best regards, [cid:image001.jpg@01D71734.32FA4640] Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com/> From: Evgheni Antropov Sent: Wednesday, March 3, 2021 12:26 To: 'Time zone mailing list' <tz@iana.org> Cc: 'Brian.Inglis@SystematicSw.ab.ca' <Brian.Inglis@SystematicSw.ab.ca> Subject: RE: [tz] Troubles with zone Asia/Gaza after tzdata2020b release Dear Brian, We’re using following version of glibc on the our Embedded devices: [root@Router8:~]# ldd --version ldd (EGLIBC) 2.18 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. [root@Router8:~]# ldd /lib/libc-2.18.so /lib/ld-linux.so.3 (0xb6fa0000) Compiled by GNU CC version 4.8.1. Compiled on a Linux 3.10.0 system on 2013-11-14. Based on the strings output it is supporting this bunch of versions: GLIBC_2.4 GLIBC_2.5 GLIBC_2.6 GLIBC_2.7 GLIBC_2.8 GLIBC_2.9 GLIBC_2.10 GLIBC_2.11 GLIBC_2.12 GLIBC_2.13 GLIBC_2.14 GLIBC_2.15 GLIBC_2.16 GLIBC_2.17 GLIBC_2.18 GLIBC_PRIVATE Also I found this structure in the strings of glibc, which perhaps describe TZif or something related with tz files __extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p (&zone_names[info->idx]) && __builtin_constant_p (__tzname[tp->tm_isdst]) && (__s1_len = strlen (&zone_names[info->idx]), __s2_len = strlen (__tzname[tp->tm_isdst]), (!((size_t)(const void *)((&zone_names[info->idx]) + 1) - (size_t)(const void *)(&zone_names[info->idx]) == 1) || __s1_len >= 4) && (!((size_t)(const void *)((__tzname[tp->tm_isdst]) + 1) - (size_t)(const void *)(__tzname[tp->tm_isdst]) == 1) || __s2_len >= 4)) ? __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst]) : (__builtin_constant_p (&zone_names[info->idx]) && ((size_t)(const void *)((&zone_names[info->idx]) + 1) - (size_t)(const void *)(&zone_names[info->idx]) == 1) && (__s1_len = strlen (&zone_names[info->idx]), __s1_len < 4) ? (__builtin_constant_p (__tzname[tp->tm_isdst]) && ((size_t)(const void *)((__tzname[tp->tm_isdst]) + 1) - (size_t)(const void *)(__tzname[tp->tm_isdst]) == 1) ? __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst]) : (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (__tzname[tp->tm_isdst]); int __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[0] - __s2[0]); if (__s1_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[1] - __s2[1]); if (__s1_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[2] - __s2[2]); if (__s1_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[3] - __s2[3]); } } __result; }))) : (__builtin_constant_p (__tzname[tp->tm_isdst]) && ((size_t)(const void *)((__tzname[tp->tm_isdst]) + 1) - (size_t)(const void *)(__tzname[tp->tm_isdst]) == 1) && (__s2_len = strlen (__tzname[tp->tm_isdst]), __s2_len < 4) ? (__builtin_constant_p (&zone_names[info->idx]) && ((size_t)(const void *)((&zone_names[info->idx]) + 1) - (size_t)(const void *)(&zone_names[info->idx]) == 1) ? __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst]) : (- (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (&zone_names[info->idx]); int __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[0] - __s2[0]); if (__s2_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[1] - __s2[1]); if (__s2_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[2] - __s2[2]); if (__s2_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[3] - __s2[3]); } } __result; })))) : __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst])))); }) == 0 From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca<mailto:Brian.Inglis@SystematicSw.ab.ca>> Sent: Tue, 2 Mar 2021 09:55:51 -0700 To: Evgheni Antropov Cc: Time zone mailing list <tz@iana.org<mailto:tz@iana.org>> Subject: RE: [tz] Troubles with zone Asia/Gaza after tzdata2020b release This may be less useful than knowing what libc code is being used on tzdata. The Yocto/OpenEmbedded project seems to be a system for managing recipes to apply thousands of patches to upstream components and tools on multiple host platforms. It appears from yocto docs and links, that depending on the yocto version, it may be based on OpenEmbedded with some earlier trimmed embedded version of glibc (perhaps 2.24 as of yocto 2.2) or musl (version?) libc, which may not have tzcode changes merged to handle current tzdata formats. Traditionally glibc/libc... use requires libc-bin which packages utilities including zic, zdump built using system libc conventions and structures. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] Best regards, [cid:image001.jpg@01D71734.32FA4640] Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com/> From: Evgheni Antropov Sent: Tuesday, March 2, 2021 10:50 To: 'Paul Eggert' <eggert@cs.ucla.edu<mailto:eggert@cs.ucla.edu>>; Tim Parenti <tim@timtimeonline.com<mailto:tim@timtimeonline.com>> Cc: Time zone mailing list <tz@iana.org<mailto:tz@iana.org>> Subject: RE: [tz] Troubles with zone Asia/Gaza after tzdata2020b release Dear Paul and Tim, Thank you for attention to this issue. We're using tzdata on the our embedded devices with ARMv7 Processor rev 2 (v7l), which has vanilla kernel [root@Router8:~]# uname -a Linux Router8 4.4.19-gdb0b54cdad #49 PREEMPT Mon Sep 30 15:10:54 EEST 2019 armv7l GNU/Linux Whole filesystem was compiled using Yocto Project 1.5 (poky-dora-10.0.0) https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora Tzdata was compiling on Ubuntu 18.04 without any additional flags and cross-compilers, just simple make install #!/bin/sh make clean #For compiling source extract tzdata and tzcode in one directory and run: make TOPDIR=$(pwd)/binaries install with additional changes related with requests from our several customers, which are not effecting on the this file. In attachment you can see whole listing of compilation. Best regards, Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com> -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu<mailto:eggert@cs.ucla.edu>> Sent: Tuesday, March 2, 2021 01:59 To: Tim Parenti <tim@timtimeonline.com<mailto:tim@timtimeonline.com>> Cc: Evgheni Antropov <Evgheni.Antropov@addgrup.com<mailto:Evgheni.Antropov@addgrup.com>>; Time zone mailing list <tz@iana.org<mailto:tz@iana.org>> Subject: Re: [tz] Troubles with zone Asia/Gaza after tzdata2020b release On 3/1/21 1:19 PM, Tim Parenti via tz wrote:
Why is the system you're testing only looking at the (legacy) 32-bit data in the v1 data block, and not using the 64-bit data in the v2+ data block? Please let us know more about the system you're running
Another possibility is that Evgheni is using a stripped down library that ignores both data blocks, and uses only the TZ string at the end. Such a library does not conform to Internet RFC 8536 but might be suitable for stripped down devices such as a router. For Asia/Gaza, the TZ string is TZ='EET-2EEST,M3.4.4/48,M10.4.4/49', where the "48" and "49" rely on the extension specified in Internet RFC 8536 section 3.3.1 and scheduled to appear in a future POSIX release. If Evgheni's library doesn't support that extension then that's the problem. Yet another possibility is that Evgheni's library simply ignores the TZ string. '-b slim' relies on the TZ string even for current timestamps, whereas '-b fat' fills out entries through 2038. However, if this were the issue I expect it would happen for timezones other than Asia/Gaza.
Please let us know more about the system you're running
Yes, that'd be helpful.
Please simplify your prompt to show only $ or > to remove noise, so we can tell where command inputs and outputs begin. Please read the Makefile to understand the process inputs and outputs. You need to run zic on the source data files distributed in the sources repo or tarball like asia et. al., *NOT* as it appears you may be doing, on the already compiled data files like /usr/share/zoneinfo/Asia/Gaza, which are the outputs of the tzdata make all (using zic) and make install processes! Please note that zic ... asia will generate ~100 output files in the default, configured, or specified location; make will generate ~2000 using a few MB. It would make more sense to zic compile/build/install the data files in and for your target environment, and run your test program there against that data. On 2021-03-12 03:30, Evgheni Antropov wrote:
Thank you for suggestion and dreads about our future troubles with tzdata.
Our Hardware Release cycle is around 10 years and of course we will change version of (e)glibc as it will be possible, but precise till to 2038.
I tried to execute zic command with suggested options on the host machine (Ubuntu 18.04), where I compiled tzdata/tzcode 2021a.
It showed those errors (I attached and trace output from strace). May be I need to compile zic with my embedded cross-compiler and run it direct on the embedded device, where is placed obsolete eglibc for correct result ?
⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -b slim -r @0/@2147483647 Gaza
"Gaza", line 1: line too long
⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -b fat -r @0/@2147483647 Gaza
"Gaza", line 1: line too long
⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -v -b fat -r @0/@2147483647 Gaza
"Gaza", line 1: line too long
⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic --help
/home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic: usage is /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic [ --version ] [ --help ] [ -v ] \
[ -b {slim|fat} ] [ -d directory ] [ -l localtime ] [ -L leapseconds ] \
[ -p posixrules ] [ -r '[@lo][/@hi]' ] [ -t localtime-link ] \
[ filename ... ]
Report bugs to tz@iana.org.
⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -v -b fat -r @0/@2147483647 -d /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/share/zoneinfo/Asia Gaza
"Gaza", line 1: line too long
⋊> /h/R/p/t/t/t/b/u/s/z/Asia strace /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -v -b fat -r @0/@2147483647 -d /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/share/zoneinfo/Asia Gaza
execve("/home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic", ["/home/RTR8A/projects/tzdata/tzda"..., "-v", "-b", "fat", "-r", "@0/@2147483647", "-d", "/home/RTR8A/projects/tzdata/tzda"..., "Gaza"], 0xbfd09290 /* 19 vars */) = 0
brk(NULL) = 0x884000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f74000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=87711, ...}) = 0
mmap2(NULL, 87711, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f5e000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\220\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1942936, ...}) = 0
mmap2(NULL, 1948192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d82000
mprotect(0xb7f57000, 4096, PROT_NONE) = 0
mmap2(0xb7f58000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d5000) = 0xb7f58000
mmap2(0xb7f5b000, 10784, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f5b000
close(3) = 0
set_thread_area({entry_number=-1, base_addr=0xb7f75100, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=6)
mprotect(0xb7f58000, 8192, PROT_READ) = 0
mprotect(0x447000, 4096, PROT_READ) = 0
mprotect(0xb7fa0000, 4096, PROT_READ) = 0
munmap(0xb7f5e000, 87711) = 0
umask(022) = 022
umask(022) = 022
brk(NULL) = 0x884000
brk(0x8a5000) = 0x8a5000
brk(0x8a6000) = 0x8a6000
openat(AT_FDCWD, "Gaza", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1213, ...}) = 0
read(3, "TZif3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 1213
write(2, "\"Gaza\", line 1: ", 16"Gaza", line 1: ) = 16
write(2, "line too long", 13line too long) = 13
write(2, "\n", 1
) = 1
_llseek(3, -809, [404], SEEK_CUR) = 0
exit_group(1) = ?
+++ exited with 1 +++
/Your best option may be following suggestions to generate data using e.g.:/
//
/ $ zic -b slim -r @0/@2147483647 <data files>/
//
/or the make equivalent to exclude leapseconds, right and posix, /
/backward, backzone, and legacy files, and include data only until 2038, /
/unless you really need some of those extra features or time range, in /
/which case you will need to update your library functions./
I'd also suggest trying "-b fat" instead of "-b slim". But at any rate,
if you're using a library that old and unsupported I have my doubts as
to whether your devices will keep working after the year 2038, no matter
what zic options you use.
Best regards,
Evgheni Antropov
Software R&D Engineer
+373 22 404 665
www.addgrup.com <http://www.addgrup.com/>
*From:* Evgheni Antropov *Sent:* Wednesday, March 3, 2021 12:26 *To:* 'Time zone mailing list' <tz@iana.org> *Cc:* 'Brian.Inglis@SystematicSw.ab.ca' <Brian.Inglis@SystematicSw.ab.ca> *Subject:* RE: [tz] Troubles with zone Asia/Gaza after tzdata2020b release
Dear Brian,
We’re using following version of glibc on the our Embedded devices:
[root@Router8:~]# ldd --version
ldd (EGLIBC) 2.18
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
[root@Router8:~]# ldd /lib/libc-2.18.so
/lib/ld-linux.so.3 (0xb6fa0000)
Compiled by GNU CC version 4.8.1.
Compiled on a Linux 3.10.0 system on 2013-11-14.
Based on the strings output it is supporting this bunch of versions:
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
GLIBC_2.18
GLIBC_PRIVATE
Also I found this structure in the strings of glibc, which perhaps describe TZif or something related with tz files
__extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p (&zone_names[info->idx]) && __builtin_constant_p (__tzname[tp->tm_isdst]) && (__s1_len = strlen (&zone_names[info->idx]), __s2_len = strlen (__tzname[tp->tm_isdst]), (!((size_t)(const void *)((&zone_names[info->idx]) + 1) - (size_t)(const void *)(&zone_names[info->idx]) == 1) || __s1_len >= 4) && (!((size_t)(const void *)((__tzname[tp->tm_isdst]) + 1) - (size_t)(const void *)(__tzname[tp->tm_isdst]) == 1) || __s2_len >= 4)) ? __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst]) : (__builtin_constant_p (&zone_names[info->idx]) && ((size_t)(const void *)((&zone_names[info->idx]) + 1) - (size_t)(const void *)(&zone_names[info->idx]) == 1) && (__s1_len = strlen (&zone_names[info->idx]), __s1_len < 4) ? (__builtin_constant_p (__tzname[tp->tm_isdst]) && ((size_t)(const void *)((__tzname[tp->tm_isdst]) + 1) - (size_t)(const void *)(__tzname[tp->tm_isdst]) == 1) ? __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst]) : (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (__tzname[tp->tm_isdst]); int __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[0] - __s2[0]); if (__s1_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[1] - __s2[1]); if (__s1_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[2] - __s2[2]); if (__s1_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[3] - __s2[3]); } } __result; }))) : (__builtin_constant_p (__tzname[tp->tm_isdst]) && ((size_t)(const void *)((__tzname[tp->tm_isdst]) + 1) - (size_t)(const void *)(__tzname[tp->tm_isdst]) == 1) && (__s2_len = strlen (__tzname[tp->tm_isdst]), __s2_len < 4) ? (__builtin_constant_p (&zone_names[info->idx]) && ((size_t)(const void *)((&zone_names[info->idx]) + 1) - (size_t)(const void *)(&zone_names[info->idx]) == 1) ? __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst]) : (- (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (&zone_names[info->idx]); int __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[0] - __s2[0]); if (__s2_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[1] - __s2[1]); if (__s2_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[2] - __s2[2]); if (__s2_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[3] - __s2[3]); } } __result; })))) : __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst])))); }) == 0
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca <mailto:Brian.Inglis@SystematicSw.ab.ca>> Sent: Tue, 2 Mar 2021 09:55:51 -0700 To: Evgheni Antropov Cc: Time zone mailing list <tz@iana.org <mailto:tz@iana.org>> Subject: RE: [tz] Troubles with zone Asia/Gaza after tzdata2020b release
This may be less useful than knowing what libc code is being used on tzdata.
The Yocto/OpenEmbedded project seems to be a system for managing recipes to apply thousands of patches to upstream components and tools on multiple host platforms.
It appears from yocto docs and links, that depending on the yocto version, it may be based on OpenEmbedded with some earlier trimmed embedded version of glibc (perhaps 2.24 as of yocto 2.2) or musl (version?) libc, which may not have tzcode changes merged to handle current tzdata formats.
Traditionally glibc/libc... use requires libc-bin which packages utilities including zic, zdump built using system libc conventions and structures.
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Best regards,
Evgheni Antropov
Software R&D Engineer
+373 22 404 665
www.addgrup.com <http://www.addgrup.com/>
*From:* Evgheni Antropov *Sent:* Tuesday, March 2, 2021 10:50 *To:* 'Paul Eggert' <eggert@cs.ucla.edu <mailto:eggert@cs.ucla.edu>>; Tim Parenti <tim@timtimeonline.com <mailto:tim@timtimeonline.com>> *Cc:* Time zone mailing list <tz@iana.org <mailto:tz@iana.org>> *Subject:* RE: [tz] Troubles with zone Asia/Gaza after tzdata2020b release
Dear Paul and Tim, Thank you for attention to this issue.
We're using tzdata on the our embedded devices with ARMv7 Processor rev 2 (v7l), which has vanilla kernel [root@Router8:~]# uname -a Linux Router8 4.4.19-gdb0b54cdad #49 PREEMPT Mon Sep 30 15:10:54 EEST 2019 armv7l GNU/Linux
Whole filesystem was compiled using Yocto Project 1.5 (poky-dora-10.0.0) https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora <https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora>
Tzdata was compiling on Ubuntu 18.04 without any additional flags and cross-compilers, just simple make install
#!/bin/sh
make clean
#For compiling source extract tzdata and tzcode in one directory and run:
make TOPDIR=$(pwd)/binaries install
with additional changes related with requests from our several customers, which are not effecting on the this file.
In attachment you can see whole listing of compilation.
Best regards,
Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com <http://www.addgrup.com>
-----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu <mailto:eggert@cs.ucla.edu>> Sent: Tuesday, March 2, 2021 01:59 To: Tim Parenti <tim@timtimeonline.com <mailto:tim@timtimeonline.com>> Cc: Evgheni Antropov <Evgheni.Antropov@addgrup.com <mailto:Evgheni.Antropov@addgrup.com>>; Time zone mailing list <tz@iana.org <mailto:tz@iana.org>> Subject: Re: [tz] Troubles with zone Asia/Gaza after tzdata2020b release
On 3/1/21 1:19 PM, Tim Parenti via tz wrote:
Why is the system you're testing only looking at the (legacy) 32-bit data in the v1 data block, and not using the 64-bit data in the v2+ data block? Please let us know more about the system you're running
Another possibility is that Evgheni is using a stripped down library that ignores both data blocks, and uses only the TZ string at the end. Such a library does not conform to Internet RFC 8536 but might be suitable for stripped down devices such as a router. For Asia/Gaza, the TZ string is TZ='EET-2EEST,M3.4.4/48,M10.4.4/49', where the "48" and "49" rely on the extension specified in Internet RFC 8536 section 3.3.1 and scheduled to appear in a future POSIX release. If Evgheni's library doesn't support that extension then that's the problem.
Yet another possibility is that Evgheni's library simply ignores the TZ string. '-b slim' relies on the TZ string even for current timestamps, whereas '-b fat' fills out entries through 2038. However, if this were the issue I expect it would happen for timezones other than Asia/Gaza.
Please let us know more about the system you're running
Yes, that'd be helpful.
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Dear Brian, Sorry for annoying and garbage in the output, I will clean them in future. Also I must to say a big thanks for your help, your suggestion is working like a charm and now this zone has correct value for enabled DST, but something goes wrong at October, when DST will disable. [cid:image002.png@01D71985.E6E21540] tzdata2021a/binaries/usr/share/zoneinfo/Asia/Gaza Fri Mar 26 21:59:59 2021 UT = Fri Mar 26 23:59:59 2021 EET isdst=0 gmtoff=7200 tzdata2021a/binaries/usr/share/zoneinfo/Asia/Gaza Fri Mar 26 22:00:00 2021 UT = Sat Mar 27 01:00:00 2021 EEST isdst=1 gmtoff=10800 tzdata2021a/binaries/usr/share/zoneinfo/Asia/Gaza Fri Oct 29 21:59:59 2021 UT = Sat Oct 30 00:59:59 2021 EEST isdst=1 gmtoff=10800 tzdata2021a/binaries/usr/share/zoneinfo/Asia/Gaza Fri Oct 29 22:00:00 2021 UT = Sat Oct 30 00:00:00 2021 EET isdst=0 gmtoff=7200 Perhaps it is related what time doesn’t like to move back in one moment and need to wait when time will get correct value for DST by itself. [cid:image003.png@01D71990.B683B970] I guess this behavior is fine for current timezone and we can close this issue. On 2021-03-12 16:59, Brian Inglis wrote:
Please simplify your prompt to show only $ or > to remove noise, so we can tell
where command inputs and outputs begin.
Please read the Makefile to understand the process inputs and outputs.
You need to run zic on the source data files distributed in the sources repo or
tarball like asia et. al., *NOT* as it appears you may be doing, on the already
compiled data files like /usr/share/zoneinfo/Asia/Gaza, which are the outputs of
the tzdata make all (using zic) and make install processes!
Please note that zic ... asia will generate ~100 output files in the default,
configured, or specified location; make will generate ~2000 using a few MB.
It would make more sense to zic compile/build/install the data files in and for
your target environment, and run your test program there against that data.
Best regards, [cid:image001.jpg@01D71983.8C024C50] Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com/> From: Evgheni Antropov Sent: Friday, March 12, 2021 12:31 To: 'Time zone mailing list' <tz@iana.org> Cc: 'Brian.Inglis@SystematicSw.ab.ca' <Brian.Inglis@SystematicSw.ab.ca>; 'Paul Eggert' <eggert@cs.ucla.edu> Subject: RE: [tz] Troubles with zone Asia/Gaza after tzdata2020b release Dear Brian and Paul, Thank you for suggestion and dreads about our future troubles with tzdata. Our Hardware Release cycle is around 10 years and of course we will change version of (e)glibc as it will be possible, but precise till to 2038. I tried to execute zic command with suggested options on the host machine (Ubuntu 18.04), where I compiled tzdata/tzcode 2021a. It showed those errors (I attached and trace output from strace). May be I need to compile zic with my embedded cross-compiler and run it direct on the embedded device, where is placed obsolete eglibc for correct result ? ⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -b slim -r @0/@2147483647 Gaza "Gaza", line 1: line too long ⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -b fat -r @0/@2147483647 Gaza "Gaza", line 1: line too long ⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -v -b fat -r @0/@2147483647 Gaza "Gaza", line 1: line too long ⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic --help /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic: usage is /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic [ --version ] [ --help ] [ -v ] \ [ -b {slim|fat} ] [ -d directory ] [ -l localtime ] [ -L leapseconds ] \ [ -p posixrules ] [ -r '[@lo][/@hi]' ] [ -t localtime-link ] \ [ filename ... ] Report bugs to tz@iana.org<mailto:tz@iana.org>. ⋊> /h/R/p/t/t/t/b/u/s/z/Asia /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -v -b fat -r @0/@2147483647 -d /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/share/zoneinfo/Asia Gaza "Gaza", line 1: line too long ⋊> /h/R/p/t/t/t/b/u/s/z/Asia strace /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic -v -b fat -r @0/@2147483647 -d /home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/share/zoneinfo/Asia Gaza execve("/home/RTR8A/projects/tzdata/tzdata2021a/tzdata2021a/binaries/usr/sbin/zic", ["/home/RTR8A/projects/tzdata/tzda"..., "-v", "-b", "fat", "-r", "@0/@2147483647", "-d", "/home/RTR8A/projects/tzdata/tzda"..., "Gaza"], 0xbfd09290 /* 19 vars */) = 0 brk(NULL) = 0x884000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f74000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=87711, ...}) = 0 mmap2(NULL, 87711, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f5e000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\220\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1942936, ...}) = 0 mmap2(NULL, 1948192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d82000 mprotect(0xb7f57000, 4096, PROT_NONE) = 0 mmap2(0xb7f58000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d5000) = 0xb7f58000 mmap2(0xb7f5b000, 10784, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f5b000 close(3) = 0 set_thread_area({entry_number=-1, base_addr=0xb7f75100, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=6) mprotect(0xb7f58000, 8192, PROT_READ) = 0 mprotect(0x447000, 4096, PROT_READ) = 0 mprotect(0xb7fa0000, 4096, PROT_READ) = 0 munmap(0xb7f5e000, 87711) = 0 umask(022) = 022 umask(022) = 022 brk(NULL) = 0x884000 brk(0x8a5000) = 0x8a5000 brk(0x8a6000) = 0x8a6000 openat(AT_FDCWD, "Gaza", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1213, ...}) = 0 read(3, "TZif3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 1213 write(2, "\"Gaza\", line 1: ", 16"Gaza", line 1: ) = 16 write(2, "line too long", 13line too long) = 13 write(2, "\n", 1 ) = 1 _llseek(3, -809, [404], SEEK_CUR) = 0 exit_group(1) = ? +++ exited with 1 +++
Your best option may be following suggestions to generate data using e.g.:
$ zic -b slim -r @0/@2147483647 <data files>
or the make equivalent to exclude leapseconds, right and posix, backward, backzone, and legacy files, and include data only until 2038, unless you really need some of those extra features or time range, in which case you will need to update your library functions.
I'd also suggest trying "-b fat" instead of "-b slim". But at any rate, if you're using a library that old and unsupported I have my doubts as to whether your devices will keep working after the year 2038, no matter what zic options you use.
Best regards, [cid:image001.jpg@01D71983.8C024C50] Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com/> From: Evgheni Antropov Sent: Wednesday, March 3, 2021 12:26 To: 'Time zone mailing list' <tz@iana.org<mailto:tz@iana.org>> Cc: 'Brian.Inglis@SystematicSw.ab.ca' <Brian.Inglis@SystematicSw.ab.ca<mailto:Brian.Inglis@SystematicSw.ab.ca>> Subject: RE: [tz] Troubles with zone Asia/Gaza after tzdata2020b release Dear Brian, We’re using following version of glibc on the our Embedded devices: [root@Router8:~]# ldd --version ldd (EGLIBC) 2.18 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. [root@Router8:~]# ldd /lib/libc-2.18.so /lib/ld-linux.so.3 (0xb6fa0000) Compiled by GNU CC version 4.8.1. Compiled on a Linux 3.10.0 system on 2013-11-14. Based on the strings output it is supporting this bunch of versions: GLIBC_2.4 GLIBC_2.5 GLIBC_2.6 GLIBC_2.7 GLIBC_2.8 GLIBC_2.9 GLIBC_2.10 GLIBC_2.11 GLIBC_2.12 GLIBC_2.13 GLIBC_2.14 GLIBC_2.15 GLIBC_2.16 GLIBC_2.17 GLIBC_2.18 GLIBC_PRIVATE Also I found this structure in the strings of glibc, which perhaps describe TZif or something related with tz files __extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p (&zone_names[info->idx]) && __builtin_constant_p (__tzname[tp->tm_isdst]) && (__s1_len = strlen (&zone_names[info->idx]), __s2_len = strlen (__tzname[tp->tm_isdst]), (!((size_t)(const void *)((&zone_names[info->idx]) + 1) - (size_t)(const void *)(&zone_names[info->idx]) == 1) || __s1_len >= 4) && (!((size_t)(const void *)((__tzname[tp->tm_isdst]) + 1) - (size_t)(const void *)(__tzname[tp->tm_isdst]) == 1) || __s2_len >= 4)) ? __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst]) : (__builtin_constant_p (&zone_names[info->idx]) && ((size_t)(const void *)((&zone_names[info->idx]) + 1) - (size_t)(const void *)(&zone_names[info->idx]) == 1) && (__s1_len = strlen (&zone_names[info->idx]), __s1_len < 4) ? (__builtin_constant_p (__tzname[tp->tm_isdst]) && ((size_t)(const void *)((__tzname[tp->tm_isdst]) + 1) - (size_t)(const void *)(__tzname[tp->tm_isdst]) == 1) ? __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst]) : (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (__tzname[tp->tm_isdst]); int __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[0] - __s2[0]); if (__s1_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[1] - __s2[1]); if (__s1_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[2] - __s2[2]); if (__s1_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (&zone_names[info->idx]))[3] - __s2[3]); } } __result; }))) : (__builtin_constant_p (__tzname[tp->tm_isdst]) && ((size_t)(const void *)((__tzname[tp->tm_isdst]) + 1) - (size_t)(const void *)(__tzname[tp->tm_isdst]) == 1) && (__s2_len = strlen (__tzname[tp->tm_isdst]), __s2_len < 4) ? (__builtin_constant_p (&zone_names[info->idx]) && ((size_t)(const void *)((&zone_names[info->idx]) + 1) - (size_t)(const void *)(&zone_names[info->idx]) == 1) ? __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst]) : (- (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (&zone_names[info->idx]); int __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[0] - __s2[0]); if (__s2_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[1] - __s2[1]); if (__s2_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[2] - __s2[2]); if (__s2_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (__tzname[tp->tm_isdst]))[3] - __s2[3]); } } __result; })))) : __builtin_strcmp (&zone_names[info->idx], __tzname[tp->tm_isdst])))); }) == 0 From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca<mailto:Brian.Inglis@SystematicSw.ab.ca>> Sent: Tue, 2 Mar 2021 09:55:51 -0700 To: Evgheni Antropov Cc: Time zone mailing list <tz@iana.org<mailto:tz@iana.org>> Subject: RE: [tz] Troubles with zone Asia/Gaza after tzdata2020b release This may be less useful than knowing what libc code is being used on tzdata. The Yocto/OpenEmbedded project seems to be a system for managing recipes to apply thousands of patches to upstream components and tools on multiple host platforms. It appears from yocto docs and links, that depending on the yocto version, it may be based on OpenEmbedded with some earlier trimmed embedded version of glibc (perhaps 2.24 as of yocto 2.2) or musl (version?) libc, which may not have tzcode changes merged to handle current tzdata formats. Traditionally glibc/libc... use requires libc-bin which packages utilities including zic, zdump built using system libc conventions and structures. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] Best regards, [cid:image001.jpg@01D71983.8C024C50] Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com/> From: Evgheni Antropov Sent: Tuesday, March 2, 2021 10:50 To: 'Paul Eggert' <eggert@cs.ucla.edu<mailto:eggert@cs.ucla.edu>>; Tim Parenti <tim@timtimeonline.com<mailto:tim@timtimeonline.com>> Cc: Time zone mailing list <tz@iana.org<mailto:tz@iana.org>> Subject: RE: [tz] Troubles with zone Asia/Gaza after tzdata2020b release Dear Paul and Tim, Thank you for attention to this issue. We're using tzdata on the our embedded devices with ARMv7 Processor rev 2 (v7l), which has vanilla kernel [root@Router8:~]# uname -a Linux Router8 4.4.19-gdb0b54cdad #49 PREEMPT Mon Sep 30 15:10:54 EEST 2019 armv7l GNU/Linux Whole filesystem was compiled using Yocto Project 1.5 (poky-dora-10.0.0) https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora Tzdata was compiling on Ubuntu 18.04 without any additional flags and cross-compilers, just simple make install #!/bin/sh make clean #For compiling source extract tzdata and tzcode in one directory and run: make TOPDIR=$(pwd)/binaries install with additional changes related with requests from our several customers, which are not effecting on the this file. In attachment you can see whole listing of compilation. Best regards, Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com> -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu<mailto:eggert@cs.ucla.edu>> Sent: Tuesday, March 2, 2021 01:59 To: Tim Parenti <tim@timtimeonline.com<mailto:tim@timtimeonline.com>> Cc: Evgheni Antropov <Evgheni.Antropov@addgrup.com<mailto:Evgheni.Antropov@addgrup.com>>; Time zone mailing list <tz@iana.org<mailto:tz@iana.org>> Subject: Re: [tz] Troubles with zone Asia/Gaza after tzdata2020b release On 3/1/21 1:19 PM, Tim Parenti via tz wrote:
Why is the system you're testing only looking at the (legacy) 32-bit data in the v1 data block, and not using the 64-bit data in the v2+ data block? Please let us know more about the system you're running
Another possibility is that Evgheni is using a stripped down library that ignores both data blocks, and uses only the TZ string at the end. Such a library does not conform to Internet RFC 8536 but might be suitable for stripped down devices such as a router. For Asia/Gaza, the TZ string is TZ='EET-2EEST,M3.4.4/48,M10.4.4/49', where the "48" and "49" rely on the extension specified in Internet RFC 8536 section 3.3.1 and scheduled to appear in a future POSIX release. If Evgheni's library doesn't support that extension then that's the problem. Yet another possibility is that Evgheni's library simply ignores the TZ string. '-b slim' relies on the TZ string even for current timestamps, whereas '-b fat' fills out entries through 2038. However, if this were the issue I expect it would happen for timezones other than Asia/Gaza.
Please let us know more about the system you're running
Yes, that'd be helpful.
On Mon, 15 Mar 2021 at 10:11, Evgheni Antropov via tz <tz@iana.org> wrote:
something goes wrong at October, when DST will disable.
Your command: date +"%Y%m%d %T" -s "20211030 00:59:55" is inherently ambiguous because 00:59:55 occurs twice on that date in your zone. date has chosen to give you the second occurrence of this time, one hour after the transition you're trying to observe has already happened. This is why your output is entirely in EET. You can unambiguously specify the UTC timestamp associated with the time you wish to inspect with something more like: date +"%Y%m%d %T" -s "20211029 21:59:55" -u -- Tim Parenti
On 2021-03-15 08:30, Tim Parenti via tz wrote:
On Mon, 15 Mar 2021 at 10:11, Evgheni Antropov via tz <tz@iana.org <mailto:tz@iana.org>> wrote:
something goes wrong at October, when DST will disable.
Your date -s commands are changing and setting the system time!
Your command: date +"%Y%m%d %T" -s "20211030 00:59:55" is inherently ambiguous because 00:59:55 occurs twice on that date in your zone. date has chosen to give you the second occurrence of this time, one hour after the transition you're trying to observe has already happened. This is why your output is entirely in EET.
You can unambiguously specify the UTC timestamp associated with the time you wish to inspect with something more like: date +"%Y%m%d %T" -s "20211029 21:59:55" -u
Option -s is intended to change and set the system time: $ date -s "20210401 23:55:55" date: cannot set date: Operation not permitted 2021 Apr 1 Thu 23:55:55 MDT To display a given time you should use only e.g. $date -ud "20211029 21:59:55+0000" +%... when -u displays the UTC equivalent. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
participants (4)
-
Brian Inglis -
Evgheni Antropov -
Paul Eggert -
Tim Parenti