[tz] timezone DB distribution

Tim Parenti tim at timtimeonline.com
Wed Aug 19 00:21:30 UTC 2020


A few answers to some of your interpretation questions—

On Tue, 18 Aug 2020 at 19:09, Juergen Naeckel via tz <tz at iana.org> wrote:

> See the first line for the zones?  It looks mismatched with the New York.
> The RULE and the [UNTIL] are probably in the wrong column.
The fields in Zone lines are delimited by whitespace, but not necessarily
any amount or type of whitespace.  In general, these files are meant to be
viewed in a standard text editor with a tabstop of 8 spaces, rather than
treated as a tab-separated values (TSV) document.

> And finally here comes my question:  In the rules, I see in the column
> several times denoted with a tailing “u” or “s”.  I think I read on one
> occasion that the times are denoted in “standard time”.  I do not recall
> anymore where that was.  But regardless,
>    1. I don’t understand what that “denoted in standard time” would mean
>    2. I definitely have no clue would the tailing “u”: would imply.
> I'll take the second one first, since it's easier: A trailing 'u' means
the time-of-day is denoted in Universal Time, or UTC.  So the October EU
rule at the bottom of your screenshot, for example, takes effect at 01:00
UTC for all zones to which it applies: which might represent a
02:00-->01:00 transition in London but 04:00-->03:00 in Athens.

The 's' for standard time is a similar principle, but more subtle.
Daylight saving is implemented by the presence of a non-zero SAVE value in
Rule lines.  This does not change the standard time itself, but rather adds
(or in some cases, subtracts) an additional offset *to* that standard
time.  For example, standard time in America/New_York is UTC-5 hrs, but
because there is currently 1 hour of DST in effect, the "total" calculated
offset is UTC-4 hrs.

Unlike how DST is observed in much of the US, which springs forward and
falls back *from* 02:00 local "wall-clock" time, based on whatever offset
was in effect immediately prior to the transition, some jurisdictions
spring forward *from* a certain time-of-day and later fall backward *to*
that same time.  The 's' allows us to simplify how we write/read those

*Example: Transitions at 02:00s*
Spring transition: *02:00 standard time* --> 03:00 daylight time
Fall transition: 03:00 daylight time --> *02:00 standard time*

*By contrast with transitions at 02:00 (without the 's', US model)*
Spring transition: *02:00 standard time* --> 03:00 daylight time
Fall transition: *02:00 daylight time* --> 01:00 standard time

As for most of your other remarks, it is worth keeping in mind that the
tzdata is truly meant to be a living historical document which is just as
easy for humans to read, interpret, and understand as it is for computers
to compile into TZif binary files or other formats.  In most cases, there
is a human legibility/understandability reason behind apparent
inefficiencies in how the data is encoded; often because it better reflects
the intent or effect of the laws that effectuated such changes.

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

More information about the tz mailing list