[Numpy-discussion] fixing up datetime

[Mark Wiebe]

On Mon, Jun 6, 2011 at 2:16 AM, Mark Dickinson <mdickinson at enthought.com>wrote:

> On Thu, Jun 2, 2011 at 5:42 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
> > Leap years are easy compared with leap seconds. Leap seconds involve a
> > hardcoded table of particular leap-seconds that are added or subtracted,
> and
> > are specified roughly 6 months in advance of when they happen by
> > the International Earth Rotation and Reference Systems Service (IERS).
> The
> > POSIX time_t doesn't store leap seconds, so if you subtract two time_t
> > values you may get the wrong answer by up to 34 seconds (or 24, I'm not
> > totally clear on the initial 10 second jump that happened somewhere).
>
> Times in the future would be hairy, too. If leap seconds are
> supported, how many seconds are there in the timedelta:
>
>    2015-01-01 00:00:00  -  2010-01-01 00:00:00
>
> ?  Is it acceptable for the result of the subtraction like this to
> change when the leap second table is updated (e.g., to reflect a newly
> added leap second on June 30th, 2012)?


This is an inherent problem with UTC, and because of choosing UTC we have a
choice of making time itself nonlinear (the current implementation) or
making minutes, hours, days, and weeks nonlinear. With the current approach,
the answer to the above will probably always be wrong (unless leap-seconds
are eliminated before adding another), and with the latter approach, the
answer to the above could be wrong until the leap-seconds are decided in the
interval.

I'm leaning towards a linear time representation, and nonlinear minutes,
hours, etc, with possibly linear versions as well. These units could be
split into 'm:UTC' and 'm:linear' for UTC and linear minutes, for example.
We could support an unambiguous version of future times by extending the ISO
8601 format with a "TAI" and/or "GPS" instead of "Z" at the end,

-Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110606/700c501b/attachment.html>