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