[M3devel] leap-second issue with Date.i3

[Mika Nystrom]

My only problem with it is that it is likely to break some programs,
those that depend on the seconds field never exceeding 60.  I think
it's legitimate to ask whether it is not more reasonable to expect
a well-written Modula-3 program(mer) to have used the contents of
Date.i3 rather than the POSIX standard to decide how to treat the
values of type Date.T....

Which are these "twilight zone" programs?  I have no idea..

     Mika


Tony Hosking writes:
>I see no problem with changing seconds to [0..60].  That matches the  
>POSIX spec nicely enough.
>
>On Nov 10, 2007, at 6:33 AM, Mika Nystrom wrote:
>
>> Hello everyone,
>>
>> I just ... added a workaround for a nasty bug I had in some code
>> of my own.  My code used Unix's localtime to convert a Time.T to a
>> Date.T using the zoneinfo files.  I'm not sure if there's a "normal"
>> way to do this in M3, so I have some messy stuff involving mutexes,
>> static storage, etc.  (Note one has to be careful when linking this
>> stuff into a program with the normal M3 conversion codes--- 
> Date.FromTime
>> and Date.ToTime---which also use (other) hidden mutexes to protect
>> some of the same data structures!)
>>
>> The issue is this.  I just realized that localtime sometimes returns
>> "60" for the seconds---namely, during a leap second!  Just copying
>> this into a Date.T will lead to a range error and a program crash.
>> Do we really want Modula-3 users to have to restart their servers
>> the moment after popping the champagne corks?  (Ok, well during
>> New Year's Eve in my time zone, but still...)
>>
>> Does anyone know how Date.T handles/should handle this?  As correct
>> as it is, I find it somewhat unsatisfying to change the seconds
>> field to [0..60], because off-by-one errors are so common in
>> programming... it's probably The Right Thing to do, though.
>>
>>      Mika