[tz] Troubles with zone Asia/Gaza after tzdata2020b release
Paul Eggert
eggert at cs.ucla.edu
Mon Mar 1 23:59:05 UTC 2021
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.
More information about the tz
mailing list