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

[Jacob Pratt]

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/2e634aa9/attachment.html>