<div dir="auto"><div>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).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Apr 4, 2023, 10:53 Brian Park <<a href="mailto:brian@xparks.net">brian@xparks.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u><div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>On Tue, Apr 4, 2023, at 02:49, Jacob Pratt via tz wrote:<br></div><blockquote type="cite" id="m_-1842395477796048927qt"><div dir="ltr"><div>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).<br></div><div><br></div><div>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.<br></div><div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><br></div><div>Jacob Pratt<br></div></div></div></div></div></div></div></div></blockquote><div><br></div></div></blockquote></div></div></div>