[Numpy-discussion] Making datetime64 timezone naive

[Alexander Belopolsky]

On Sat, Oct 17, 2015 at 6:59 PM, Chris Barker <chris.barker at noaa.gov> wrote:

> If anyone decides to actually get around to leap seconds support in numpy
> datetime, s/he can decide ...


This attitude is the reason why we will probably never have bug free
software when it comes to civil time reckoning.   Even though ANSI C has
the difftime(time_t time1, time_t time0) function which in theory may not
reduce to time1 - time0, in practice it is only useful to avoid overflows
in integer to float conversions in cross-platform code and cannot account
for the fact some days are longer than others.

Similarly, current numpy.datetime64 design ties arithmetic with encoding.
This makes arithmetic easier, but in the long run may preclude designs that
better match the problem domain.

Note how the development of PEP 495 has highlighted the fact that allowing
binary operations (subtraction, comparison etc.) between times in different
timezones was a design mistake.  It will be wise to learn from such
mistakes when redesigning numpy.datetime64.

If you ever plan to support civil time in some form, you should think about
it now.  In Python 3.6, datetime.now() will return different values in the
first and the second repeated hour in the "fall-back fold."   If you allow
datetime.datetime to numpy.datetime64 conversion, you should decide what
you do with that difference.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20151018/4a3bc466/attachment.html>