On Thu, Aug 6, 2015 at 11:11 AM, Chris Barker - NOAA Federal <[email protected]> wrote: > M-A s note made this all a bit more clear to me: business use cases > are a lot more concerned with the Calendar than actual elapsed time. > On the other hand, I do scientific applications, and am far more > concerned with accurate elapsed time.
Another point that some people often don't understand is that when they run something like $ TZ=UTC date Thu Aug 6 18:28:49 UTC 2015 on their POSIX compliant computers that run ntpd to sync with the atomic clock, they get a bona fide UTC time with all leap seconds accounted for. It is only when they do $ TZ=UTC date +%s 1438885729 the number they get is *not* the number of seconds elapsed since UTC midnight of 1970-01-01. This number is some 26 seconds off, but how many people care about this number? On the other hand the value that everyone looks at (Thu Aug 6 18:28:49 UTC 2015) is correct on POSIX systems except for that one second that by strict UTC rules should be displayed as 23:59:60. (And, depending on how paranoid your system admin is, you possibly see delayed time for a few hours before and after the leap second insertion.) _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
