[Numpy-discussion] timezones and datetime64

[Mark Wiebe]

On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen <pav at 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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130403/3fd28c46/attachment.html>