std.date
Jonathan M Davis
jmdavisProg at gmx.com
Wed Nov 17 09:51:30 PST 2010
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
More information about the Digitalmars-d
mailing list