[Numpy-discussion] timezones and datetime64
Wed Apr 3 20:02:37 CDT 2013
On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen <firstname.lastname@example.org> wrote:
> 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.
I think this would be nice. Would it be a stretch to extend the ISO syntax
One problem with trying to give technically correct answers for the
UTC/Posix format is that it can't actually represent the leap-second, so a
datetime64 + timedelta64 could produce an unrepresentable moment in time.
> 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
I like this kind of strict approach. To go along with it, there would need
to also be a more flexible string parsing method where you could specify
> 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.
The np.datetime_as_string function has a start of some of this (looks like
I neglected to document it properly, sorry!).
In : t = np.datetime64('2013-04-03T13:21Z')
In : t
In : np.datetime_as_string(t, timezone='local')
In : np.datetime_as_string(t, timezone='UTC')
In : np.datetime_as_string(t, timezone=pytz.timezone('US/Eastern'))
> 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...
I think it's most straightforward to leave it wrong for Posix-format
datetimes, but add a TAI timezone where it will produce correct results.
> Pauli Virtanen
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion