[Numpy-discussion] Making datetime64 timezone naive
chris.barker at noaa.gov
Wed Oct 14 11:59:53 EDT 2015
On Tue, Oct 13, 2015 at 3:58 PM, Nathaniel Smith <njs at pobox.com> wrote:
> > However, numpy datetime is optimized for compact storage and fast
> computation of absolute deltas (actual hours, minutes, seconds... not
> calendar units like "the next day" ).
> Except that ironically it actually can't compute absolute deltas
> accurately with one second resolution, because it does the POSIX time thing
> of pretending that all UTC days have the same number of seconds, even
> though this is not true (leap seconds).
Note that I said "fast", not "accurate" -- but the leap second thing may be
one more reason not to call datetime64 "UTC" -- who's to say that "naive"
time should include leap seconds :-)
Also, we could certainly add a leap seconds implementation to the current
infrastructure -- the real technical problem with that is how to keep the
leap-seconds table up to date -- we have no way to know when there will be
leap-seconds in the future...
Also -- this may be one more reason to have a selectable epoch -- then
you'd likely overlap fewer leap-seconds in a given us case.
> This isn't really relevant to anything else in this thread, except as a
> reminder of how freaky date/time handling is.
yup -- it sure is.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion