std.date

[Jonathan M Davis]

On Wednesday 17 November 2010 12:37:18 Kagamin wrote:
> Jonathan M Davis Wrote:
> > > 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.
> 
> An exception will be thrown, this is tested:
> 
> assertExcThrown!(DateTimeException, (){TimeOfDay(0, 0, 0).second =
> 60;})(LineInfo());

Except that _no_ calculation in std.datetime would _ever_ result in a second 
being 60. A user program would have to do that by trying to create a TimeOfDay 
or DateTime (which contains a TimeOfDay) with a second value of 60.

The question is what string value or DateTime/TimeOfDay value SysTime gives when 
converting from a time that is during that leap second application when the 
TimeZone being used handles leap seconds. It's either going to give 59 or 00, 
but never 60. I'd have to look at the code in PosixTimeZone to see which.

> > 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.
> 
> That's probably why Oracle and Solaris rebooted on 2009-01-01.

Possibly. But that would mean that their code handled the 60th second (and if it 
did, they would likely have done it properly). Unless there is some way to get a 
time out of the OS which gives you a 60th second, and they were using that 
method of getting the time, they never would have even seen a value of 60 for 
the seconds anywhere. You have to work at it to get that 60th second. Most stuff 
just ignores leap seconds completely. If whatever they did caused an exception 
(like TimeOfDay would throw) and _that_ is what took the system done, then they 
have other major problems.

I have no idea what really caused the problem, but my guess would be that it was 
code that assumed something which didn't hold when that new leap second was hit, 
and it resulted in a segfault. Given how robust that kind of software has to be, 
I would not expect it to go down from a mere exception, unless it were a _major_ 
one - like what D would typically have as an Error.

- Jonathan M Davis