24:00 versus 23:59:59--insights?
There are a few places with rules such as "... lastFri 0:00 ..." that should be "... lastThu 24:00 ..." One possibility is to rewrite the rules that way; doing so buys error messages from pre-1998 versions of zic. Another possibility is to rewrite the rules as "... lastThu 23:59:59 ..." which works with pre-1998 versions of zic but is a second off. A third way is to use 24:00 and, where it is used, include a comment about either upgrading zic or using the 23:59:59 dodge. I'd appreciate any insights on how to go forward. --ado
Whatever you decide, please don't introduce a work around that makes up-to-date systems wrong (even by a second). It wouldn't be too hard to get zic to output a pre-1998 compatible version of its input files, which could be posted along with the new files on every release. julian -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: 28 April 2009 12:50 To: tz@lecserver.nci.nih.gov Subject: 24:00 versus 23:59:59--insights? There are a few places with rules such as "... lastFri 0:00 ..." that should be "... lastThu 24:00 ..." One possibility is to rewrite the rules that way; doing so buys error messages from pre-1998 versions of zic. Another possibility is to rewrite the rules as "... lastThu 23:59:59 ..." which works with pre-1998 versions of zic but is a second off. A third way is to use 24:00 and, where it is used, include a comment about either upgrading zic or using the 23:59:59 dodge. I'd appreciate any insights on how to go forward. --ado http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
There are a few places with rules such as "... lastFri 0:00 ..." that should be "... lastThu 24:00 ..." One possibility is to rewrite the rules that way; doing so buys error messages from pre-1998 versions of zic. Another possibility is to rewrite the rules as "... lastThu 23:59:59 ..." which works with pre-1998 versions of zic but is a second off. A third way is to use 24:00 and, where it is used, include a comment about either upgrading zic or using the 23:59:59 dodge. I'd appreciate any insights on how to go forward.
I think it'd be better to have the rules state 24:00 if the transition is at 24:00 (instead of either stating 23:59:59 or using the 23:59:59-means-24:00 solution). I'd expect that users of an 11-year-old version of zic will be able to do the simple replacement of 24:00 with 23:59:59 on their end, especially if there are comments by the 24:00 values, and it's better to optimize for what I assume is the much more common case of a user with a more recent version of zic. In particular, I feel like if either 23:59:59 solution is used it will become standard practice, leading to either one second errors or added interpretation complexity forever while providing benefit to a small and continually shrinking set of pre-1998 users. - Adam
<<On Tue, 28 Apr 2009 07:50:02 -0400, "Olson, Arthur David (NIH/NCI) [E]" <olsona@dc37a.nci.nih.gov> said:
There are a few places with rules such as "... lastFri 0:00 ..." that should be "... lastThu 24:00 ..." One possibility is to rewrite the rules that way; doing so buys error messages from pre-1998 versions of zic.
Let me add my voice to the chorus that says those still using eleven-year-old versions of zic deserve to lose. And let us not forget that that the compiled file format is backward-compatible, so even if these users have ancient systems that they can't replace, they can compile the data files on a newer machine and copy the zones they need to their older device. -GAWollman
On 28-Apr-2009, Olson, Arthur David (NIH/NCI) wrote:
There are a few places with rules such as "... lastFri 0:00 ..." that should be "... lastThu 24:00 ..." One possibility is to rewrite the rules that way; doing so buys error messages from pre-1998 versions of zic. Another possibility is to rewrite the rules as "... lastThu 23:59:59 ..." which works with pre-1998 versions of zic but is a second off. A third way is to use 24:00 and, where it is used, include a comment about either upgrading zic or using the 23:59:59 dodge. I'd appreciate any insights on how to go forward.
Strictly my personal opinion, I think that we should use 24:00:00. A related question: is it possible for a jurisdiction to specify a rule that says something like the time change will occur at one minute after 24:00 on the second Thursday? That's not the same thing as 0:01 on the second Friday. It's 0:01 on Friday after the second Thursday, and there is no current way to express that (that I could find). Do we need to allow times like 24:01 or even 25:00? I don't need answers now; I'm just raising the questions for thought. Perhaps we shouldn't worry about it until and unless something like that happens. I think it's unlikely, but possible, for awful rules like that to occur. Dave C. Groton, CT
On Tue, Apr 28, 2009 at 07:50:02 -0400, Olson, Arthur David (NIH/NCI) [E] wrote:
There are a few places with rules such as "... lastFri 0:00 ..." that should be "... lastThu 24:00 ..." One possibility is to rewrite the rules that way; doing so buys error messages from pre-1998 versions of zic. Another possibility is to rewrite the rules as "... lastThu 23:59:59 ..." which works with pre-1998 versions of zic but is a second off. A third way is to use 24:00 and, where it is used, include a comment about either upgrading zic or using the 23:59:59 dodge. I'd appreciate any insights on how to go forward.
I'm not someone who would be affected personally by any of these changes, but it seems to me that 10+ years is long enough to wait before making use of the "24:00" notation, support for which presumably was added to zic precisely for this situation. Am I correct that the binary zoneinfo files compiled by more recent versions of "zic' could still be used by older versions of the timezone runtime? If that's true, it definitely seems reasonable to ask people still running pre-1998 versions of zic on some machine to find a newer machine to use for generating their zoneinfo files (assuming they don't want to just upgrade zic on the old machine for whatever reasons). Even if the zoneinfo files aren't compatible, it still seems fair enough ask those few (presumably) people still running such old versions to work around these entries so that the rest of the user population can benefit from having the "correct" definitions. (Putting comments explaining the situation certainly makes sense.) On Tue, Apr 28, 2009 at 07:53:39 -0400, Olson, Arthur David (NIH/NCI) [E] wrote:
Yet another possibility is to add a special case to zic to treat instances of 23:59:59 as if they were 24:00; this lets us use 23:59:59 in input files to make pre-1998 versions of zic happy and to get correct-to-the-second results out of post-2009 versions of zic.
The downside is that 1998-through-2008 versions of zic would be a second off, while all those versions would be correct we just went ahead and switched to using "24:00". This special treatment could also come back to haunt us if some government ever decided to make 23:59:59 an actual transition time.... (It also seems less than ideal to have different versions of zic producing different output from the same input files.... I don't know if that situation has ever occured before [due to bugfixes, etc.], but it seems wise to avoid the situation if we have a choice.) To me it seems better to ask that people who really need to use pre-1998 versions of zic do some sort of preprocessing on their input files than to require everyone else to upgrade zic (or do their own preprocessing) to get correct transitions for the time zones in question. Nathan ---------------------------------------------------------------------------- Nathan Stratton Treadway - nathanst@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
participants (6)
-
Adam Vartanian -
Dave Cantor -
Garrett Wollman -
Julian Cable -
Nathan Stratton Treadway -
Olson, Arthur David (NIH/NCI) [E]