[tz] Java & Rearguard

Steve Summit scs at eskimo.com
Mon Jun 10 10:53:06 UTC 2019


Paul Eggert wrote:
>Steve Summit wrote:
> > Now, it's true, isdst might not be the best key to use for this
> > sort of thing any more.
>
> The only partially-relevant info in tzdata consists of abbreviations
> like "IST" and "PDT" and unfortunately these abbreviations are well-
> documented to be ambiguous and historically inaccurate in some cases.

I was about to say, "But they only have to be unambiguous within
a single tzdb id."  That is, it doesn't matter if PDT can mean
either Pacific Daylight Time or Philippines Daylight Time, as
long as one's in America/Los_Angeles and one's in Asia/Manila.
But what you knew and I was overlooking is that *IST is ambiguous
even within Europe/Dublin*, meaning Irish Summer Time before 1968,
and Irish Standard Time after.

So while it seems like the abbreviation ought to be a much better
key than the dst flag, for the one case that really matters, it's
not much help at all.

And the other problem with abbreviations, of course, is that they
don't always exist.  When they don't, they're replaced with UTC
offsets, and UTC offsets aren't good as keys for ICU/CLDR/Java's
purposes, as they can change even when the zone names don't.

While I'm stating the obvious, I'll also point out two other
values that won't work as keys either, namely tt_abbrind, and
the "time type" indices that link transition times and timezone
descriptions together in tz files.  Those indices are both
closely associated with the "edges" at which zone names change,
but neither of them is at all normative, as they're essentially
made up by zic, and could differ from run to run.


More information about the tz mailing list