Stephen Colebourne wrote:
On Tue, 4 Jun 2019 at 17:49, Steve Summit <scs@eskimo.com> wrote:
So the analogous question for me is, "What are Java programs using isDaylightSavings for?
As discussed when the issue started a couple of years ago, the flag is used to select the name to display:
public String getDisplayName(boolean daylight, int style, Locale locale) https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/TimeZ...)
Thanks. So if I understand correctly, most/all of these calls to isDaylightSavings have nothing to do with Daylight Saving Time per se; they're just getting a more or less opaque token to use to fetch a CLDR string. And I think that sort of thing happens all over the place; it's basically one of the widespread assumptions which, for better or worse, lots of programmers make. Ideally we'd all be thinking about one or two arbitrarily-different kinds of time per year, but it's so easy to assume that one of them is called "dst", and that it happens in the summer, and that it's always an hour ahead of the other kind. So perhaps there's an opportunity here to help everyone out by trying to promulgate a vocabulary which emphasizes the arbitrariness. Instead of having a "dst" flag which is either true or false, what if we had a "kind" field which was a small integer from 0 to N-1? (Of course, internal to tz files, that's exactly what we have already.) I'm not sure what I mean by "what if we had", here, but if it's our contention that "standard versus DST" is an insufficient and/or obsolete distinction, that we'd like people to move beyond, there might be better ways of motivating that evolution than by setting isdst to 1 during the winter in Ireland and busting people's assumptions. (As an aside: Is it my imagination, or was there a time when C had an array of 1, 2, or maybe more than 2 time zone strings, and you used tm_isdst as an index into them, such that tm_isdst functioned as a sort of an opaque token even though it had "dst" in its name?)