<div dir="ltr"><div dir="ltr"><div dir="ltr" class="gmail_attr"><br class="gmail-Apple-interchange-newline">On Tue, 26 Jul 2022 at 15:53, Guy Harris via tz <<a href="mailto:tz@iana.org">tz@iana.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> If it means the Rule lines in .zi files, that's not intended for end-user consumption. That information is absent from the TZif files output by zic. So I doubt whether you meant that.<br><br>Given that he said "look up the rules in the zic input file (because the compiled blobs lack this information)", he's presumably aware of that, and probably *did* mean "the Rule lines in .zi files".<br><br>If some software needs information based on that - i.e., needs to know when the current tzdb region, or a particular tzdb region, changed or will change its offset from UTC or its abbreviation - then perhaps its developers should propose a new API that implementations such as the tzdb reference implementation could provide.  (Hopefully those developers are aware that a given tzdb region can change, over time, which rule sets it uses!)</blockquote><div><br></div><div>For exactly this reason, I would argue that attempts to extract raw input rules to, say, display general UI descriptions such as "Daylight Saving Time in effect from the second Sunday in March at 02:00 through the first Sunday in November at 02:00" would generally be misguided.</div><div><br></div><div>I've seen some interfaces that assist in zone selection by displaying the next upcoming clock change for a given zone, which is already straightforward to get from compiled TZif files.  If you want to provide an end-user with a somewhat fuller picture of how a zone might behave seasonally, you could extend this to the next (pair of) forward and backward transitions, if any, which in most cases would be adequate to describe the next year or so.  For America/New_York today, this might look something like "Clocks go backward 1 hour on Sunday 6 November 2022 at 02:00 and go forward 1 hour on Sunday 12 March 2023 at 02:00."  (Of course, it would be easy to naïvely render those timestamps with their post-transition times of 01:00 and 03:00, respectively, but the conventional pre-transition 02:00 could be determined by intentionally calculating the display times with their pre-transition offsets.)  Note that, because DST can be negative, it is more useful/descriptive to describe the direction and amount of actual clock movements than the state of an arbitrary toggle.</div><div><br></div><div>To handle some common edge cases, consider describing the next transition however far ahead it may be (to allow for a region announcing a change to its time zone or rules several years out), but maybe only look ahead ~12 months from that point for a second one (to avoid implying recurrent seasonality that may not exist).<br></div></div><div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--<br>Tim Parenti</div></div></div></div>