[Numpy-discussion] timezones and datetime64
pav at iki.fi
Wed Apr 3 19:27:07 EDT 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...
More information about the NumPy-Discussion