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

Mark Wiebe mwwiebe@gmail....
Mon Jun 6 17:12:56 CDT 2011

On Mon, Jun 6, 2011 at 3:47 PM, Mark Dickinson <mdickinson@enthought.com>wrote:

> On Mon, Jun 6, 2011 at 9:24 PM, Mark Wiebe <mwwiebe@gmail.com> wrote:
> Sorry for being dense, but:
> > 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
> This bit I understand, but:
> > and an ambiguity-resolution in the few cases that need it,
> Where does the ambiguity come from?  (Assuming we're not more than 6
> months into the future.)  There would be ambiguity with POSIX time,
> but doesn't UTC manage to specify any point in time unambiguously?

If you add one minute to an added leap-second, you end up at second 60 in a
minute which has only 60 seconds, and you have to fall back to second 59 or
forward to second 0 of the next minute. Also, if you add a minute which
should land where a leap-second was removed, you have to fall back to second
58 or second 0 of the next minute.

> [...]
> > Does this design sound reasonable to people?
> Python's datetime and timedelta types use POSIX time (i.e., just
> pretend that leap seconds don't exist and hope that everything works
> out okay).  Would this cause problems when converting between Python
> and NumPy types?

Converting from the Python type to the NumPy type has a problem for removed
leap-seconds (of which there are currently none), and converting from the
NumPy type to the Python type has a problem for added leap-seconds. To allow
for round-tripping to/from python objects, I think I would just make it
return the underlying 64-bit number instead of a Python datetime object.
This is also what it does for years outside of the range Python accepts.

> I guess part of the point of this work is that with
> full datetime support in NumPy the need for such conversions would be
> relatively rare, so maybe there's no real problem here.

Yeah, as long as the calendar-related API is sufficient, I think that's

But having thought quite hard about some of these issues for Python's
> datetime module recently, I'm sceptical that leap second support is
> really that valuable, and fear that having it turned on by default
> will cause nasty surprises for those who have no need to think about
> leap seconds and write code that assumes that a minute has 60 seconds.

I think that by having some default ambiguity-resolution rules for leap
seconds, things will generally work out as people expect. On the other hand,
with POSIX time, anybody that wants things precise with respect to
leap-seconds is automatically excluded. The potential surprises from
leap-seconds seem milder than the surprises from time zones and the
multitude of possible calendars out there. I found it disconcerting that
datetime.datetime.now() returns local time with no time zone indication on
it. Here's how I've resolved that issue in NumPy:

>>> datetime.datetime.now()
datetime.datetime(2011, 6, 6, 17, 10, 32, 444658)
>>> np.datetime64('now')

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20110606/94814158/attachment.html 

More information about the NumPy-Discussion mailing list