Thank you very much for your clarifications. It turns out that the C library that I'm using (uClibc) only seems to handle TZ strings with POSIX rules. Best regards Andre Brizido -----Original Message----- From: Zefram [mailto:zefram@fysh.org] Sent: 5 de agosto de 2017 00:09 To: André Domingos Brízido Cc: tz@iana.org Subject: Re: [tz] Israel POSIX timezone string error on release 2017b? Andre Domingos Brizido wrote:
the last line of the time zone database may contain the POSIX timezone string,
Not really "the", as that implies that there's only one applicable to the zone, and in particular implies that it describes the zone's whole behaviour or at least its current behaviour. The purpose of the rule given at that point in the tzfile is specifically to describe the (projected) future behaviour of the zone following the last explicit transition.
But if I understood correctly, the POSIX specification (http://pubs.opengroup.org/onlinepubs/9699919799/) states that the value '26' is out of range. It should be between zero and 24.
The current version of the tzfile format uses a not-quite-POSIX-TZ string format in which some of these bounds are explicitly looser than they are in POSIX. This was done so that essentially any DST rule understood by zic can be expressed in a tzfile. Tzfile parsers, if they're interested in future behaviour past 2038, need to understand this more liberal format. This change comes at the expense of the ability to feed the TZish line from a tzfile into anything that understands the POSIX TZ format and get meaningful results. But, because of the limited significance of that part of the tzfile format as discussed above, the results that one could get were of limited utility anyway, only useful in conjunction with the tzfile's explicit transitions. This line from the tzfile was never a suitable substitute for the full tzfile, even when one is only concerned about current times.
My linux system does not display the correct timezone if I use the string 'IST-2IDT,M3.4.4/26,M10.5.0' as the contents of /etc/TZ.
There is no POSIX TZ string that expresses the DST rules represented by that string. (Let alone the rules used by Israel prior to 2013, which depended on the Hebrew calendar and were not even understood by zic.) -zefram