[Numpy-discussion] timezones and datetime64

Chris Barker - NOAA Federal chris.barker at noaa.gov
Thu Apr 4 13:01:51 EDT 2013

On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
> On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen <pav at iki.fi> wrote:

>> 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'?

Is there no standard for that already -- it's not mentioned in
ISO_8601, but maybe there is something else.

> 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.

I'm a bit confused by that -- how it it different than leap-days?

Benjamin Root wrote:
> A use case for finer resolution than seconds (in our field, no less!) is lightning data.
> At the last SciPy conference,  a fellow meteorologist mentioned how difficult it was
> to plot out lightning data at resolutions finer than microseconds (which is the
> resolution of the python datetime objects).

sure -- but now you can only do that for lightning in 1970.... how
useful is that? My point was that without the ability to choose your
epoch, high-resolution time is pretty worthless. Also considering the
leap-second and TAI vs. UTC issues, you really wouldn't want to use an
epoch far away from your time-of-interest for high-resolution data

> By the way, my 12th Rule of Programming is "Never roll your own datetime"

no kidding! Why I was (am) really happy to see it in numpy...

Daniele Nicolodi wrote:
> I'm not aware of any library that handles the conversion from UTC to
> TAI. I would like to know if there is one.

In keeping with the above -- I doubt the numpy project wants to write
and maintain its own from scratch... I"m guessing we'll need to punt
on that.

Francesc Alted wrote:
> When Ivan and me were discussing that, I remember us deciding that such
> a small units would be useful mainly for the timedelta datatype, which
> is a relative, not absolute time.  We did not want to make short for
> very precise time measurements, and this is why we decided to go with
> attoseconds.

I thought about that -- but if you have timedelta without datetime,
you really just have an integer -- we haven't bought anything.

It seems we have a number of somewhat orthogonal issues with DateTime
in front of us:

1) How to handle (or not) time zones

2) How (whether) to handle leap-seconds, etc.

3) Whether to support TAI time (or is that the same as the above?)

4) Should we add a flexible epoch?

I suggest we create separate threads for these, discuss a bit more,
then have at the NEP.

I'll start one for (1).

I don't have the expertise nor use-case for (2) and (3), so I'll punt,
but someone can pick it up.

I'll start one for (4) also, though I'm not sure I have much to say,
other than that I think it's good idea. My naive view is that it would
be pretty easy, actually, but I could be very wrong there.



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

More information about the NumPy-Discussion mailing list