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

Excellent, thanks for the explanation, should be an easy enough fix (should
actually simplify the code)

On Fri, May 25, 2012 at 11:16 AM, Zefram <[email protected]> wrote:

> Anthony Ball wrote:
> >So is that a bug in DateTime?
>
> No, it's just one of the ways in which date `arithmetic' isn't.
>
> >                              If I subtract one epoch time from another
> and
> >add shouldn't they end up together?
>
> The form of epoch seconds implemented by DateTime doesn't count
> leap seconds.  So in the time scale supplied by DateTime it is *not*
> a linear count of elapsed seconds from a starting point.  However,
> DateTime *does* supply some facilities that operate on linear seconds.
> You have presumably mixed the two kinds of operation.
>
> To get arithmetic to work as you expect, you can work entirely in
> epoch seconds.  Do your arithmetic on the numerical values, never on
> DateTime objects.  Use DateTime to convert the resulting values to
> objects, which you can then feed to DT:TZ objects.  This is appropriate
> for your application.  The alternative, to work in linear seconds (as
> perceived by DT), wouldn't be any better, because timezone objects at
> best just ignore the leap seconds that that would make visible to them.
>
> -zefram
>