Israel POSIX timezone string error on release 2017b?
Hello According to the Linux manual (http://man7.org/linux/man-pages/man5/tzfile.5.html) the last line of the time zone database may contain the POSIX timezone string, which is the case of the files generated by following the instructions in https://www.iana.org/time-zones/repository/tz-link.html I've downloaded the latest release (2017b) and I obtain the following POSIX string for Israel: [/usr/share/zoneinfo]# tail -n 1 Israel IST-2IDT,M3.4.4/26,M10.5.0 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. 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. Best regards Andre Brizido
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
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
André Domingos Brízido wrote:
According to the Linux manual (http://man7.org/linux/man-pages/man5/tzfile.5.html)
That manual is out of date, and documents only up through tzdb version 2. You're looking at a version 3 file. I sent a bug report to mtk.manpages@gmail.com suggesting that they update their copy of the man page. Also, I spruced up the tzdb man page as described here: http://mm.icann.org/pipermail/tz/2017-August/025207.html This should make it easier for their project to simply copy the upstream file.
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.
That TZ setting works for me, if I set the TZ environment variable to it. I am using Fedora 26, which uses glibc 2.25. By mentioning "/etc/TZ" I suspect you are using some other C library. Which C library and version number is it? We can send its maintainers a bug report.
Indeed I'm using another library: uClibc v.0.9.33.2 which is quite old and hasn't have any new release in a long time. Also according to the FAQs: "The uClibc time functions get timezone information from the TZ environment variable, as described in the Single Unix Specification Version 3. See http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html for details on valid settings of TZ". In other words, uClibc cannot handle the strings from version 3 tz files. Thank you very much for your clarifications. Best regards Andre Brizido -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: 5 de agosto de 2017 04:38 To: André Domingos Brízido; Time zone mailing list Subject: Re: [tz] Israel POSIX timezone string error on release 2017b? André Domingos Brízido wrote:
According to the Linux manual (http://man7.org/linux/man-pages/man5/tzfile.5.html)
That manual is out of date, and documents only up through tzdb version 2. You're looking at a version 3 file. I sent a bug report to mtk.manpages@gmail.com suggesting that they update their copy of the man page. Also, I spruced up the tzdb man page as described here: http://mm.icann.org/pipermail/tz/2017-August/025207.html This should make it easier for their project to simply copy the upstream file.
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.
That TZ setting works for me, if I set the TZ environment variable to it. I am using Fedora 26, which uses glibc 2.25. By mentioning "/etc/TZ" I suspect you are using some other C library. Which C library and version number is it? We can send its maintainers a bug report.
André Domingos Brízido wrote:
In other words, uClibc cannot handle the strings from version 3 tz files.
Ah, OK, that is a shortcoming of uClibc, in that it does not support the TZ settings for Israel's predicted future, and similarly for western Greenland. I filed a bug report for that here: https://bugs.busybox.net/show_bug.cgi?id=10181 Please try the fix and follow up there.
On 07/08/17 17:29, Paul Eggert wrote:
André Domingos Brízido wrote:
In other words, uClibc cannot handle the strings from version 3 tz files.
Ah, OK, that is a shortcoming of uClibc, in that it does not support the TZ settings for Israel's predicted future, and similarly for western Greenland. I filed a bug report for that here:
https://bugs.busybox.net/show_bug.cgi?id=10181
Please try the fix and follow up there.
Here are a couple of other relevant bug reports (both submitted by the same person, it seems): https://bugs.busybox.net/show_bug.cgi?id=5936 http://www.austingroupbugs.net/view.php?id=661 -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Web: http://www.mev.co.uk/ )=-
participants (4)
-
André Domingos Brízido -
Ian Abbott -
Paul Eggert -
Zefram