[tz] OpenJDK/CLDR/ICU/Joda issues with Ireland change

Steve Summit scs at eskimo.com
Sat Jan 27 02:09:52 UTC 2018

Brian Inglis wrote:
> On 2018-01-26 06:54, Steve Summit wrote:
> > ...in many people's minds, the isdst-related portions of
> > the TZ API have already been pretty severely deprecated for at
> > least 10 years (maybe even 20).
> Who has been deprecating which parts of the ABI/API where?

I said "In many people's minds", so I concede that to some extent
I'm talking here about subjective reality, not objective fact.
But it has seemed pretty obvious (and for a very long time) that
several pieces of the traditional, SysV, Posix time interface
were either useless, or broken, or both.  I'll explain what I
mean, but I'm reasonably sure this is not just one man's opinion:
it is very much along the lines of what (for example) Robert Elz
and Guy Harris have been arguing in this thread; it's what Eric
Raymond argues at http://www.catb.org/esr/time-programming/, etc.

If you're trying to convert back and forth between
machine-readable timestamps (i.e. time_t) and human-readable
times, in C, these functions are useful:

	localtime, gmtime, mktime, strftime

These functions and global variables are either not useful,
or downright broken:

	ctime, asctime, timezone, tzname

This function, though not standard, is so necessary that it ought
to be standard, and one shouldn't feel too bad about using it
even though it's not:


And then there are the struct tm members.  Most of them are
useful.  But tm_isdst is not remotely useful, for reasons which
I think have been adequately exposed in this thread (but I can
elaborate if necessary).  And, finally, the common struct tm
extensions, tm_gmtoff and tm_zone, are so necessary that, again,
I wouldn't fault anyone (no matter how zealous about writing
portable, standards-compliant code) for using them if available.

The notions that timezone, tzname, and tm_isdst are not useful,
and that functional invocations of localtime, gmtime, and
strftime are much more useful, are coupled with a parallel
dichotomy between two separate models for how to think about time
and time zones at all.  Should we represent a time zone simply as
a base offset, and a "dst" offset, and a pair of names, and rules
for deciding which (two) times during a year to switch to and
from the "dst" offset?  Or should we use a mapping -- an
arbitrarily complex one -- between UTC and local time, with the
offset and the name both being multivariate functions of the time
being converted?  (Again, the evident superiority of one model
should be reasonably obvious based on this thread, but there may
be more to say in separate messages.)

More information about the tz mailing list