Not a bug in DateTime. This is consistent with the C libraries that underpin 
Perl and other stuff. If you call the internal time() function every second 
over a leap second you'll see the same epoch value twice. It's about defining 
what the epoch second actually means. It's the number of solar seconds since 
jan 1, 1970. 

As the earth's rotation doesn't evenly divide into the number of seconds that 
have elapsed, we occasionally need to skip or add a second. Just like we have 
to add a day every ~4 years. 

The problem is that epoch seconds are serial so it's a lot weirder. If we had 
epoch days, you'd see a double up every ~4 years so that years were always a 
multiple of 365. (Imagine if leap seconds actually skewed the epoch by a second 
how hard it would be to use them?  (eg: time() % 86400))

Cheers!
Rick Measham

On 25/05/2012, at 23:08, Anthony Ball <[email protected]> wrote:

> So is that a bug in DateTime? If I subtract one epoch time from another and
> add shouldn't they end up together? Or is it just too weird to code for?
> 
> Maybe a better solution than adding seconds would be just moving to that
> epoch slice, I'd have to create a new datetime using from_epoch (unless
> there is a way to do that on an existing object other than date math) but
> it would remove any math inconsistencies.
> 
> I was wondering about leap seconds since it only happened in that one time
> frame but wasn't sure where to check for it, thanks.
> 
> On Fri, May 25, 2012 at 6:40 AM, Zefram <[email protected]> wrote:
> 
>> Anthony Ball wrote:
>>> I never had any luck finding anything to give me the future DST changes
>> for
>>> a timezone
>> 
>> We don't have an API for that.  We've discussed it a bit, and will most
>> likely add such a thing to the DT:TZ API after we've switched to the
>> reimplemented DT:TZ, scheduled for 2012-09-01.
>> 
>>>                                              Now however the second
>>> change in 2012 is coming up one second short,
>> 
>> Smells like a leap second issue.  There's a leap second scheduled for
>> 2012-06-30T23:59:60Z.
>> 
>> -zefram
>> 
> -- 
> Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
> content filtering.http://www.mailguard.com.au
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1EOfrXTUQv/96CbBBv21MNXe8uQWnhfs/0.8
> 
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Reply via email to