On Tue, Oct 13, 2015 at 3:58 PM, Nathaniel Smith <n...@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.bar...@noaa.gov
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
