On Thu, 16 Jan 2003, Yitzchak Scott-Thoennes wrote:
> > my $dt = DateTime->new( year => 1997, month => 6, day => 30,
> > hour => 23, minute => 59, second => 59,
> > ( timezone => $utc_zone ) ... or ...
> > ( timezone => $other_zone ) ... or ...
> > ( floating => 1 ) ... or ...
> > );
> >
> > $dt += DateTime::Duration->new( seconds => 2 );
> >
> >What is $dt now?
> >
> >If it were UTC, the time would be "1997-07-01 00:00:00", right? If it
> >were some other time zone the time would be "1997-07-01 00:00:01". But if
> >its floating, how do you decide?
>
> I think you assume no leap second, so it would be "1997-07-01 00:00:01".
Ok, how about if I do this ;)
my $dt = DateTime->new( year => 1997, month => 6, day => 30,
hour => 23, minute => 59, second => 59,
( timezone => $utc_zone ) ... or ...
( timezone => $other_zone ) ... or ...
( floating => 1 ) ... or ...
);
$dt += DateTime::Duration->new( days => 1 );
????
There's a 50/50 chance you should apply the leap second ;)
Oooh, we'll use Quantum::Superpositions! Hehe, that should satisfy
everybody.
Here's some references to this problem online:
http://lists.ximian.com/archives/public/evolution-hackers/2000-December/001273.html
Above basically says that its in the current time zone at all times, which
implies checking for time zone changes whenever the object is accessed.
That's certainly doable for us as well, and handles the leap sceond
problem.
Internally, if a time zone change is detected, we simply change the
timezone, which will trigger date math to adjust the UTC time, which may
trigger a leap second change. This is simple for the user and relatively
simple for implementation, because date changes will _always_ have to
trigger a check for leap seconds, I think (though obviously there are
optimizations that could be applied to avoid that).
http://www.ietf.org/rfc/rfc2445.txt - plenty of discussion of floating
time
This says basically the same thing.
> Interestingly, Olsen has support for leap seconds occurring either at
> midnight UTC ("Stationary") or at midnight for each time zone ("Rolling").
Eek! Let's start with just UTC, for my sanity ;)
> But only the UTC variety are entered in their table. They also have
> support for double leap seconds and one or two removed seconds so that
> a minute could be anywhere from 58-62 seconds long.
A potential -1 leap second is mentioned every where I've read about leap
seconds. I have heard of >1 leap seconds though. Adding support for that
to an existing leap seconds implementation would be pretty trivial,
though.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
