[Numpy-discussion] dealing with datetime UTC vs linear time
Mon Jun 6 17:12:56 CDT 2011
On Mon, Jun 6, 2011 at 3:47 PM, Mark Dickinson <firstname.lastname@example.org>wrote:
> On Mon, Jun 6, 2011 at 9:24 PM, Mark Wiebe <email@example.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
> > 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(2011, 6, 6, 17, 10, 32, 444658)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion