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

[Paul Eggert]

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.