[tz] Irish Standard Time vs Irish Summer Time

Michael H Deckers michael.h.deckers at googlemail.com
Sat Dec 9 19:01:31 UTC 2017


    On 2017-12-09 14:00, Mark Davis ☕️ wrote:

> I'm not quite sure what the motivation for such a potentially 
> destabilizing change its. If the only purpose is to call one of the 
> two times "Irish Standard Time" and the other "GMT", then that seems a 
> simple matter of changing the naming, not other changes to the data.
>
     I think you raise an important point here.

     The proposal at hand has as its (only observable)
     effect that the dst bit is set to 1 during Irish
     winter time (UTC), and 0 during Irish standard time
     (UTC + 01 h).

     Taken together with all the other cases (where the dst
     bit value 1 indicates daylight saving or summer time
     as opposed to standard time) this implies that the
     semantics of the dst bit would be:

        The dst bit is set to 1 while the time
        scale differs from what is considered
        to be standard time for the time zone, such
        as when daylight saving time or summer time
        is used.

     That is a perfectLy possible semantics --
     but it just is not the semantics currently
     described with the tzdb releases. In fact,
     the current description conforms with
     the tm_isdst bit defined in the international
     standards for the C language and for POSIX from
    1989 until today for the tm_isdst member of
    struct tm:

       The value of tm_isdst shall be positive if Daylight Savings Time
       is in effect, 0 if Daylight Savings Time is not in effect, and
        negative if the information is not available."

     (Note the spurious s after saving!) For instance,
     in newctime we read:
        Tm_isdst is non-zero if summer time is in effect.
     Thus, the current definition of the dst bit
     of a time zone time scale appears to be:

        The dst bit is set to 1 while the time
        scale represents daylight saving time or
        summer time.

     Of course one can change the current definition --
     but in this case we should make an explicit
     decision to do so, after considering all
     the effects of such a change, and we also should
     make sure that the change is consistently documented
     in all the interfaces specified by tzdb.

     This is a design question, not just the question of
     whether a particular patch is OK.

     Michael Deckers.




More information about the tz mailing list