Re: Issue with finding next DST change, date math error?

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
>