[tz] Changing 24:00 to 0:00 where possible

[Brian Park]

I am curious to hear that your TZDB parsing is exposed to your end-users and is in the critical path. I would have thought that the parsing would be done offline (e.g. after each TZDB release), and the TZDB data would be converted into a different format that is more amenable to the computation that your code is performing.

With regards to the data format of the TZDB, I have not seen great problems with the parsing. It's the *interpretation* of that data which is incredibly difficult and tricky. I'm not sure that using different format, like JSON, would help with the interpretation part.

With regards to 25:00, I believe that should be interpreted as: "This transition occurs at exact 25 hours after the beginning of the first Saturday on or after the 8th of September". The implicit 'w' for "wall time" is not a real physical clock on the wall, but a hypothetical clock keeping time in the local time zone just before the transition.


On Tue, Apr 4, 2023, at 12:24, Jacob Pratt wrote:
> That is definitely what I intend to do for where it's necessary, but the code path will almost certainly be slower, which is a significant factor to consider in my situation (it's a widely used library).
> 
> Ultimately it would be great if there were a generated file in a common format (such as JSON) so that everyone doesn't have to write their own parser. But that's a separate issue.
> 
> With regard to Japan, did the clock read 24:59:59 before going to 0:00? I'm not sure how else to interpret 25:00.
> 
> On Tue, Apr 4, 2023, 10:53 Brian Park <brian at xparks.net> wrote:
>> __
>> I wrote my own TZDB parser as well, and my early versions ran into these problems. The solution was to implement an internal version of the "date/time" class/type that could handle 24:00 without complaining. Your code will have to handle Japan's bizarre 25:00 rule for 1948-1951 anyway (Rule  Japan 1948  1951  - Sep Sat>=8  25:00 0 S). Once it handles 25:00, it should be able to handle the 24:00.
>> 
>> I don't speak for the TZDB maintainers, but my impression is that these 24:00 correspond directly to how the regulations and laws are written. That probably makes it easier for human beings to maintain them.
>> 
>> On Tue, Apr 4, 2023, at 02:49, Jacob Pratt via tz wrote:
>>> While writing a parser for tzdb files, I noticed that some rules are for a given date at 24:00, rather than the following day at 0:00. While in some cases this is unavoidable (Egypt), in others there is no reason this is necessary (Belize).
>>> 
>>> I think it would be reasonable to change 24:00 to 0:00 where possible, incrementing the day, day of week, and month as appropriate. This would reduce the need for special casing values to those that have a technical reason.
>>> 
>>> Jacob Pratt
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20230404/c410acc9/attachment.html>