[tz] Java & Rearguard

[Steve Summit]

Wow.  Thanks for all that detail, Guy.

For anyone at risk of drowning in it, though, the simpler answer
(as I think someone else already pointed out) is that the second
argument to gettimeofday wasn't sufficient and wasn't relevant to
most application code anyway.

The vast majority of application programs just want to convert
UTC to local time, or local back to UTC.  They don't really care
precisely where the C localtime() function gets its timezone data
from.  Putting that data into an environment variable (as SysV
and Posix did) or into a database keyed by an environment
variable (as the ado tzdb does) offered huge advantages, and
moreover the mechanism was more or less invisible to most
application code.  So abandoning gettimeofday's second argument
was easy, almost natural.

But I'm not sure that's the right question to ask.  The more
relevant question for this thread, I think, is "Why has the
C/Unix world mostly abandoned the tz_isdst field of struct tm?"

And the answer to that question is that tm_isdst isn't usually
necessary or sufficient, either.  On output from localtime(),
anyway, tm_isdst doesn't tell you anything you need to know.
What you may be more interested in is a name or abbreviation
for the local time zone, or the time delta between the local
time and UTC.  tm_isdst is of no use (at least, not by itself)
in answering those questions; what you really want is the tm_zone
and tm_gmtoff fields (which are, sadly, not official, but that's
another story).

So the analogous question for me is, "What are Java programs
using isDaylightSavings for?  What problems would it cause them
if isDaylightSavings's output changed, or if it disappeared?
Would some other differently-defined function serve the needs
of those programs better?"

I don't know much about Java (and nothing about its
standardization process), so I take Stephen Colebourne at his
word when he says that isDaylightSavings is not going to change
for the foreseeable future.  But I do still wonder what programs
are using it for.

* If they're using it as part of their own homebrew conversion
  between UTC and local time, well, they're doing it wrong, and
  they really ought to change.

* If they know about time zones and the details of time zones
  (perhaps as part of a user interface that presents these
  details to users), they definitely need to have a good
  understanding of the situation in a region that observes DST or
  some similar switchover.  But as Ireland and this thread have
  shown us, a model based on a simple binary distinction between
  "standard time" and "DST" doesn't really work.  I wonder if,
  for some of those programs at least, slavishly presenting
  Ireland as standard=GMT,DST=UTC+1=IST doesn't cause those
  programs to do precisely the wrong thing?  I wonder if a
  different choice for "DST" mapping (or a different API)
  wouldn't serve those programs' needs better?

* If they're doing something else, I'd really like to know what
  it is.

I guess my bottom line is, again, to wonder what preserving
the status quo for Java DST indications actually accomplishes.
Yes, it upholds (some part of) a standardized API, and interface
stability is obviously good.  But in the last analysis, does a
Java program that cares abut DST *really* want to be told that
a timestamp in the summer in Ireland does use it, or would it
rather be told something else?