[tz] Proposal: validation text file with releases

[Guy Harris]

On Jul 15, 2015, at 12:10 PM, Jon Skeet <skeet at pobox.com> wrote:

> If the tzdata isn't really intended to be consumed - if we should really only consume the zic output, and anything else is somewhat questionable, then why distribute the tzdata at all?

So that people can edit them to add updates/fixes, run them through zic for their own purposes, and send them back to the maintainers.

So that people can see the comments giving history, sources, etc..

> Why not just distribute the zic output files?

See above.

> As for DST vs STD time not being relevant in software - while Windows doesn't (mostly) use tzdata, it does allow you to specify a time zone and exclude DST from that. Anyone wanting to mimic that behaviour but using the tz data can only do it if they know the DST component of the overall offset.

So how is that behavior useful?  Yes, if you're living in Arizona, you *could* say "Mountain Time, without DST", but, with tzdata, you could also say "America/Phoenix" (or, even better, say "I live here" and have the system figure out that "here" is in Arizona and give you "America/Phoenix" without having to deal with "butbutbutbutbut I live in Scottsdale!").

I.e., is the fact that Microsoft allows that a consequence of Microsoft deciding to handle "time zones" in the conventional sense of the term, plus a "daylight savings time shifts occur" flag that can be applied to an arbitrary zone, rather than in the tzdata sense of "a region that has kept its clocks the same way over time since 1970" including DST rules (so that if region A is at the same offset-from-UTC as region B but didn't follow DST in the same fashion as region B at some point between 1970 and now, they're in separate tzdata time zones), the only reason for that behavior?

> 	• zic and the reference API do not expose the STD/DST components of the overall offset, and are unlikely to start doing so

Perhaps, but it's not as if the reference API is constrained to be the ANSI C/POSIX API, so, *if* it were deemed useful to expose those two components separately, it could be extended to do so.

Note, however, that it's not as if, within a given tzdata time zone, the STD component will be the same over time.  Regions can decide to change which time zone, in the conventional sense, they're in; this does not require them to change what tzdata time zone they're in, unless part of a region covered by a given tzdata time zone changes which conventional time zone they're in but another part doesn't, in which case we need to split the tzdata time zone.

I.e., programs that are given access to the STD and DST components of the overall offset should not misuse them.  ("Assuming that STD represents some value that has remained constant since 1970" counts as "misuse".) In what fashion *are* they used by software in the real world?