[tz] IANA timezone database - request to add Omaha, Nebraska

Tim Parenti tim at timtimeonline.com
Tue Jul 26 21:11:39 UTC 2022

On Tue, 26 Jul 2022 at 15:53, Guy Harris via tz <tz at iana.org> wrote:

> > 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.
> 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".
> 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!)

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.

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.

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).

Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20220726/7aeb8d51/attachment.htm>

More information about the tz mailing list