[Numpy-discussion] Making datetime64 timezone naive

[Chris Barker]

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.

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

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...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20151014/0f735a81/attachment.html>