[tz] Java & Rearguard

Fred Gleason fredg at paravelsystems.com
Mon Jun 3 16:44:34 UTC 2019


On Sun, 2019-06-02 at 18:10 +0100, Stephen Colebourne wrote:
> As I, and others, have said, I don't believe there is any appetite to
> change the meaning of DST in Java - the pain would be far too great
> with no or negative benefits.

Perhaps it would be helpful to review what happened in the POSIX world
in a similar situation. The man page for gettimeofday(3) on Linux has
contained this narrative for as long as I can remember (mid/late
1990s):

*** snip snip ***
NOTES
       Traditionally, the fields of struct timeval were of type long.

       The tz_dsttime field has never been used under Linux.
       Thus,  the  following is purely of historic interest.

       On old systems, the field tz_dsttime contains a symbolic 
       constant (values are given below) that indicates in which part 
       of the year  Daylight Saving  Time is in force.  (Note: this 
       value is constant throughout the year: it does not indicate
       that DST is in force,  it  just  selects  an algorithm.) 
       The  daylight  saving time algorithms defined are as follows:

           DST_NONE     /* not on DST */
           DST_USA      /* USA style DST */
           DST_AUST     /* Australian style DST */
           DST_WET      /* Western European DST */
           DST_MET      /* Middle European DST */
           DST_EET      /* Eastern European DST */
           DST_CAN      /* Canada */
           DST_GB       /* Great Britain and Eire */
           DST_RUM      /* Romania */
           DST_TUR      /* Turkey */
           DST_AUSTALT  /* Australian style with shift in 1986 */

       Of course it turned out that the period in which Daylight Saving
       Time is  in  force  cannot  be given by a simple algorithm, one
       per country; indeed, this period is determined by unpredictable 
       political decisions. So this method of representing timezones
       has been abandoned.
*** Snip snip ***

I find it significant that POSIX apparently ended up ditching an entire
API element in favor of adding a model capabale of handling the full
complexities of civil timekeeping (as they were understood at the
time); a move which surely must have caused heartburn for many POSIX-
based applications in use at that time.

Can anyone here recall the context and complexities surrounding this
transition?

Cheers!


|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |             Chief Developer             |
|                           |             Paravel Systems             |
|---------------------------------------------------------------------|
|         A room without books is like a body without a soul.         |
|                                                                     |
|                                                         -- Cicero   |
|---------------------------------------------------------------------|



More information about the tz mailing list