I can confirm that there can be funny behavior on 32 bit O/S if zic runs without -b fat Sent from my iPhone
On Mar 2, 2021, at 10:08, tz-request@iana.org wrote:
Send tz mailing list submissions to tz@iana.org
To subscribe or unsubscribe via the World Wide Web, visit https://mm.icann.org/mailman/listinfo/tz or, via email, send a message with subject or body 'help' to tz-request@iana.org
You can reach the person managing the list at tz-owner@iana.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of tz digest..."
Today's Topics:
1. Re: Troubles with zone Asia/Gaza after tzdata2020b release (Evgheni Antropov)
----------------------------------------------------------------------
Message: 1 Date: Tue, 2 Mar 2021 08:49:33 +0000 From: Evgheni Antropov <Evgheni.Antropov@addgrup.com> 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 Message-ID: <5b8eea9809f34e658c6529708744c1ad@addgrup.com> Content-Type: text/plain; charset="us-ascii"
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.