[Numpy-discussion] dealing with datetime UTC vs linear time

Mark Wiebe mwwiebe@gmail....
Mon Jun 6 15:24:17 CDT 2011


I've given the UTC leap-second issue a bit of thought, and here are some
related requirements I've come up with:

1. The underlying data representation of datetime64 should be linearly
related to time.
2. Default calendar functionality should be based on ISO 8601, and by
reference be in UTC
3. It should be possible to unambiguously specify a time at any point in the
past or the future, and get such a representation back from NumPy.

One problem trying to resolve these requirements with respect to UTC is that
either the underlying time has jump discontinuities, like in POSIX time_t,
or minutes, hours, days, and weeks are sometimes one second longer or
shorter. Additionally, it's not possible in general to specify UTC times
with second resolution 6 or more months in advance.

Here's what I propose NumPy's datetime do:

A. Use a linear time representation, point 1. Conversion to/from ISO 8601
strings thus requires leap-second knowledge.
B. Extend ISO8601 with a "TAI" suffix which is just like "Z" but has no
leap-seconds and is 34 seconds ahead of an equivalent "Z" time at the
present. This satisfies point 3.
C. Add a metadata item which chooses between "UTC" and "TAI". For seconds
and finer, converting between UTC and TAI units is safe, and for minutes and
coarser, is unsafe. UTC involves leap-seconds and an ambiguity-resolution in
the few cases that need it, while in TAI everything is linear. Local time
zone-based formatting is only available for UTC datetimes.

By default, all units will be UTC, but either TAI or UTC can be specified
like 'M8[D:TAI]' or 'M8[h:UTC]'.

Does this design sound reasonable to people?

Cheers,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20110606/816a1db2/attachment.html 


More information about the NumPy-Discussion mailing list