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 <zef...@fysh.org> 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 >
