(cross-posting to tz and IBM-MAIN) Hi, TZData, On a Linux system, I see: 1043 $ uname -a Linux Bunsen5-PG 4.9.0-11-686-pae #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) i686 GNU/Linux 1044 $ cat /usr/share/zoneinfo/Asia/Tel_Aviv | tail -1 IST-2IDT,M3.4.4/26,M10.5.0 1045 $ ... This would seem to be Month 3, Week 4, Day 4, hour 26. 26? Is that supposed to be 02:00 the next day? But POSIX says: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag... ... The hour shall be between zero and 24, and the minutes (and seconds) -if present-between zero and 59. The result of using values outside of this range is unspecified. z/OS (which supports only POSIX format) seems to ignore that TZ (as allowed by "unspecified") and use UTC0: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1... (It doesn't specify.) Ouch! -- gil
On 12/31/19 1:05 PM, Paul Gilmartin via tz wrote:
1044 $ cat /usr/share/zoneinfo/Asia/Tel_Aviv | tail -1 IST-2IDT,M3.4.4/26,M10.5.0 1045 $
... This would seem to be Month 3, Week 4, Day 4, hour 26. 26? Is that supposed to be 02:00 the next day?
Yes.
POSIX says:
That's old news. Please see Internet RFC 8536 section 3.3.1 and <http://austingroupbugs.net/view.php?id=1252>.
On 2019-12-31, at 16:46:00, Paul Eggert wrote:
... That's old news. Please see Internet RFC 8536 section 3.3.1 and <http://austingroupbugs.net/view.php?id=1252>.
My apologies for the pleonasm; I excerpted bug 1252 and RFC 8536 to IBM-MAIN. In fact the user reporting the problem is in Israel. I see: https://en.wikipedia.org/wiki/Israel_Summer_Time#2013%E2%80%93Present If the end of IDT falls on Rosh Hashana, the Jewish New Year, then IDT will end on the first Monday after October 1.[8] On July 8, 2013, the Israeli Knesset approved the bill to extend IDT even further. According to the bill, IDT will begin on the Friday before the last Sunday of March, and end on the last Sunday of October.[9] So it depends on the Metonic Cycle. POSIX format is unlikely to handle that. Thanks, gil
On Tue, 31 Dec 2019 at 18:46, Paul Eggert <eggert@cs.ucla.edu> wrote:
Please see Internet RFC 8536 section 3.3.1 and <http://austingroupbugs.net/view.php?id=1252>.
RFC 8536 §3.3.1 extensions state only "[t]he hours part of the transition times may be signed and range from -167 through 167", but does not itself define the behavior if minutes are specified. Of course, this is not a major concern when the hours are positive (or 0), as the intent is fairly straightforward, and the current POSIX definitions being extended imply as much by stating that "[t]he time [of transition] has the same format as [the] offset", just without sign. As it happens, Pacific/Chatham is currently the only zone that must specify minutes in its TZ string, since its DST transitions are linked to New Zealand's main islands and therefore don't take place at the top of the hour, local time: "<+1245>-12:45<+1345>,M9.5.0/2:45,M4.1.0/3:45" For negative hours, Austin Group issue 0001252 recommends that '-3:30' stands for 20:30 the previous day, but this may not be the most instructive example. If, for example, New Zealand were to change its spring transition date from "last Sunday in September" to, instead, "Sunday preceding last Monday in September" (and similarly for fall in April), this would result in: "<+1245>-12:45<+1345>,M9.5.1/-21:15,M4.1.1/-20:15" While this logically follows how we tend to think of "negative time" (i.e., as a "countdown" that negates the entire expressed time interval), it may not be obvious to the casual observer that "-21:15" and "-20:15" refer to local times that are nominally at "45 past the hour". Since this affects how one should approach parsing, perhaps an example not on the half-hour might make that intent a bit clearer. -- Tim Parenti
participants (3)
-
Paul Eggert -
Paul Gilmartin -
Tim Parenti