[Numpy-discussion] timezones and datetime64

Pauli Virtanen pav@iki...
Wed Apr 3 18:27:07 CDT 2013


Mark Wiebe <mwwiebe <at> gmail.com> writes:
> It seems to me that adding a time zone to the datetime64
> metadata might be a good idea, and then allowing it to be
> None to behave like the Python naive datetimes.

Probably also TAI and UTC/Posix.

Converting from one format to the other is problematic since
all of them (except TAI afaik) require looking things up in
regularly updated databases. Not only restricted to conversions,
but also arithmetic, `b - a`. Affects also UTC/Posix via leap
seconds --- this probably doesn't usually matter, but if we want
to be strict, it's not good to ignore the issue.

On the string representation level, one possible way to go
could be to require UTC markers for UTC times, and disallow
them for local times::

    datetimeutc64('2013-02-02T03:00:00')      # -> exception
    datetimeutc64('2013-02-02T03:00:00Z')     # -> valid
    datetimeutc64('2013-02-02T03:00:00-0200') # -> valid
    datetime64('2013-02-02T03:00:00')         # -> valid
    datetime64('2013-02-02T03:00:00Z')        # -> exception
    datetime64('2013-02-02T03:00:00-0200')    # -> exception

Dealing with actual TZ handling could be left to be the
responsibility of the users, maybe with some helper conversion
functions on the Numpy side.

This still leaves open the question how leap seconds should be
handled, or if we should just ignore the results and let
people live with 
datetime64('2012-01-01T00:00:00Z') - datetime64('1970-01-01T00:00:00Z')
being wrong by ~ 30 seconds...

-- 
Pauli Virtanen



More information about the NumPy-Discussion mailing list