[tz] Troubles with zone Asia/Gaza after tzdata2020b release

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Wed Mar 3 16:06:05 UTC 2021

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

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

More information about the tz mailing list