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.