[Numpy-discussion] timezones and datetime64
Chris Barker - NOAA Federal
Thu Apr 4 12:01:51 CDT 2013
On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe <firstname.lastname@example.org> wrote:
> On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen <email@example.com> 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
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
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
More information about the NumPy-Discussion