[Datetime-SIG] Fwd: Calendar vs timespan calculations...

[Chris Barker]

> On Aug 3, 2015, at 9:11 PM, Tim Peters <tim.peters at gmail.com> wrote:
>
> Sorry about this.  I don't want to talk about leap seconds anymore,

Nor do I, but

TL;DR -- leap seconds are in the definition of UTC. And there are use
cases (see below) that python may want to support at some point. So it
would be good to have infrastructure in place so that someone could
implement it in the future (probably as a third party lib).

Now,  if you actually want to read more about this:

> The basic template for doing timeline arithmetic is:
>
> 1. Convert the datetime(s) to UTC.
> 2. Do straightforward classic arithmetic in UTC.
> 3. Convert back to original timezone (except for datetime-datetime
> subtraction, in which case we're done).
>
> This works because, in step #2, classic arithmetic is the same as
> timeline arithmetic.  However, that relies on that Python's current
> implementation of UTC ignores leap seconds. The approximated UTC is an
> instance of "naive time".

If I have this right, the datetime object encodes time using the
proleptic Gregorian calendar, with no leap seconds -- yes? Is that
what TAI time is? From:

http://www.timeanddate.com/time/international-atomic-time.html

It appears so.

> TAI
> is an instance of naive time, that's the obvious choice.  So add:
>
> 1.5.  Use the frickin' leap second table to convert to TAI.
>
> and, in 2, s/UTC/TAI/, and
>
> 2.5  Use the frickin' leap second table to convert back to UTC.

Exactly. So for now, we simply document that Naive time IS TAI time,
and that the to-from UTC methods on the tzinfo objects are actually
to-from TAI ( renaming them is probably out of the question, though)

Then if anyone ever wants to implement leap seconds (I.e. a proper
UTC), then they create a UTC tzinfo object that converts properly
to-from TAI with that frikin' leap second table. ( and all the other
time zones to match...).

I still think that the base datetime object should be UTC, which would
include leap seconds, but it's too late for that. (hmm -- could a user
simply plug in a new datetime object, instead of a new tzinfo objects? but
anyway, as long as the door is open one way or another, then we're good for
now.

Use case:

In the netcdf CF metadata standard:

http://cfconventions.org

Datetimes are encoded as "some time span since an epoch", i.e.
"seconds since 1970-01-01T0:0:0". The epoch can be anything, and the units
can be any well-defined reasonable unit -- seconds, hours, days.

Then elsewhere, you can specify the Calendar used. And this gets ugly
because there are some weird ones -- for instance, some climate models use
a 360 day year!  There was recently a big huge discussion about how to
specify the variations of the Gregorian calendar -  whether leap seconds
are in play or not, etc. This is uglier than it should be because a lot
(most?) time libraries don't do leap seconds, but many people _think_ they
are using UTC, when they are not.  And for the most part, it's close enough.

When using this encoding, it would be smart to use an epoch close to the
time of your data / model results -- for instance, the zeroth time step of
your model. And some people do this. In that case, you're likely to only
cross maybe one or two leap-seconds. But in practice, a lot of folks encode
their time using an epoch farther away from their data -- sometimes Unix
epoch (that makes sense), and sometimes ones that seem totally arbitrary to
me (maybe their time library uses it?). In this case, when the times are
encoded back to calendar representation, they are often off by 26 seconds
if a time lib that doesn't support leap-seconds is used. In practice, even
26 seconds probably doesn't matter in most cases, but when you are working
with datetimes (like Python's) with a resolution of microseconds, errors
that large are perceived to be significant, and can lead to actual errors
(like getting time steps from different sources out of order), if the code
is not written carefully to account for the limited precision of the inputs.

OK -- I'm done with leap seconds.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150804/08e35e62/attachment-0001.html>