std.date

[Jonathan M Davis]

On Wednesday, November 17, 2010 04:15:52 Kagamin wrote:
> Daniel Gibson Wrote:
> > > Synchronization can fail if the code asserts that number of seconds is
> > > not greater than 59 (Jonathan's lib does the same, I think). Is it the
> > > cause?
> > 
> > How are leap seconds handled on a computer anyway? Does the clock really
> > count to 60 seconds (instead of 59) before the next minute starts, or is
> > the clock just slowed down a bit (like it's - IIRC - done when changing
> > the time with NTP or such)?
> 
> This is how it looked on linux:
> 
> bash-2.05b# date
> Thu Jan 1 00:59:58 CET 2009
> bash-2.05b# date
> Thu Jan 1 00:59:59 CET 2009
> bash-2.05b# date
> Thu Jan 1 00:59:60 CET 2009
> bash-2.05b# date
> Thu Jan 1 01:00:00 CET 2009
> bash-2.05b# date
> Thu Jan 1 01:00:01 CET 2009
> bash-2.05b#

That's the standard, but supposedly it varies a bit in how it's handled - at 
least if you read it up on Wikipedia.

I'd have to go digging in std.datetime again to see exactly what would happen on 
a leap second, but IIRC you end up with either 59 twice or 00 twice. Unix time 
specifically ignores leap seconds, and in 99.9999999999% of situations, if you 
have a 60th second, it's a programming error, so TimeOfDay considers 60 to be 
outside of its range and throws if you try and set its second to 60.

SysTime is really the only type where it would make much sense to worry about 
leap seconds, but since the only way that you're going to get them is if you go 
out of your way by using a PosixTimeZone which starts with "right/" for your 
time zone, it seemed silly to worry about it overly much. The _system time_ 
ignores leap seconds after all, _even_ if you use one of the time zones that 
starts with "right/" as your system's time zone. So, the result is that if you 
use one of the PosixTimeZones with leap seconds, it will correctly adjust for 
leap seconds except when adding or removing a leap second, at which point, you'd 
get a duplicate time for two seconds in a row in the case of an addition and 
probably would skip a second in the case of subtraction (though that's actually 
probably the correct behavior for a subtraction - not that they've ever 
subtracted an leap seconds yet). It might be less than ideal if you _really_ 
care about leap seconds, but allowing for a 60th second could really mess with 
calculations and allow for bugs to go uncaught in user code. So, allowing for a 
60th second when adding a leap second would help an extreme corner case at the 
cost of harming the normal case, and I decided against it.

- Jonathan M Davis