[Numpy-discussion] timezones and datetime64
Mark Wiebe
mwwiebe@gmail....
Wed Apr 3 20:02:37 CDT 2013
On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen <pav@iki.fi> 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
with '2013-02-02T03:00:00TAI'?
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
alternative behaviors.
> 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 [10]: t = np.datetime64('2013-04-03T13:21Z')
In [11]: t
Out[11]: numpy.datetime64('2013-04-03T06:21-0700')
In [12]: np.datetime_as_string(t, timezone='local')
Out[12]: '2013-04-03T06:21-0700'
In [13]: np.datetime_as_string(t, timezone='UTC')
Out[13]: '2013-04-03T13:21Z'
In [14]: np.datetime_as_string(t, timezone=pytz.timezone('US/Eastern'))
Out[14]: '2013-04-03T09:21-0400'
> 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.
Thanks,
Mark
>
> --
> Pauli Virtanen
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20130403/3fd28c46/attachment.html
More information about the NumPy-Discussion
mailing list