[tz] Troubles with zone Asia/Gaza after tzdata2020b release
Evgheni Antropov
Evgheni.Antropov at addgrup.com
Fri Mar 12 10:30:53 UTC 2021
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 at 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 at 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 at iana.org>
Cc: 'Brian.Inglis at SystematicSw.ab.ca' <Brian.Inglis at 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 at 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 at 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 at SystematicSw.ab.ca<mailto:Brian.Inglis at SystematicSw.ab.ca>>
Sent: Tue, 2 Mar 2021 09:55:51 -0700
To: Evgheni Antropov
Cc: Time zone mailing list <tz at iana.org<mailto:tz at 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 at 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 at cs.ucla.edu<mailto:eggert at cs.ucla.edu>>; Tim Parenti <tim at timtimeonline.com<mailto:tim at timtimeonline.com>>
Cc: Time zone mailing list <tz at iana.org<mailto:tz at 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 at 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 at cs.ucla.edu<mailto:eggert at cs.ucla.edu>>
Sent: Tuesday, March 2, 2021 01:59
To: Tim Parenti <tim at timtimeonline.com<mailto:tim at timtimeonline.com>>
Cc: Evgheni Antropov <Evgheni.Antropov at addgrup.com<mailto:Evgheni.Antropov at addgrup.com>>; Time zone mailing list <tz at iana.org<mailto:tz at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20210312/f9f6885d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2877 bytes
Desc: image001.jpg
URL: <http://mm.icann.org/pipermail/tz/attachments/20210312/f9f6885d/image001-0001.jpg>
More information about the tz
mailing list