Re: os.clock conversion to milliseconds under MacOS X

[William Ahern <william@...>]

On Wed, Dec 17, 2014 at 07:17:22PM -0500, Joseph Wallace wrote:
> On 12/17/2014 02:52 PM, Isaac Dupree wrote:
> > 
> > That documentation cannot be correct on Unix-time systems if there is a
> > leap second between t1 and t2.
> > 
> > (For example, in UTC Unix time, 1341144000 - 1341057600 = 86400 but
> > there were actually 86401 seconds from June 30, 2012 12:00:00 UTC to
> > July 1, 2012 12:00:00 UTC.  That said, even Python's documentation
> > doesn't clearly tell me whether its time deltas treat leap seconds as
> > being zero seconds long; we seem to be resigned to IERS-initiated
> > software bugs every few years.)
> > 
> 
> Depends if you are using UTC Unix time (traditional) or TAI Unix time
> (the "right/" tzdata files). ;)

It's better to treat Unix time (aka POSIX time) as unrelated to UTC or TAI,
regardless of your system settings. POSIX time is literally defined as 86400
seconds per day. It has no concept of leap seconds, unlike UTC or TAI. It
follows that the definition of a "second" in POSIX is not the same as the
metric unit, "second", used by UTC and TAI. Same spelling, same
pronounciation, and even a passing similarity, but two entirely different
units of time.

You cannot consistently convert a POSIX timestamp to UTC or TAI with an
accuracy of 1 second. It's fundamentally a lossy conversion.

The benefit of POSIX time is that calculation of civil date-times is
incredibly easy, both past and future. It's trivial to calculate the
accurate minute, hour, day, day of week, month, and year, just not the
accurate UTC or TAI second or sub-second.

On the other hand, with UTC and TAI it's not possible to calculate all
future dates accurately, and for calculating past dates you need a table of
leap seconds. Very ugly.

Personally, I prefer the POSIX the definition of time. It's an elegant hack.
When converting to UTC it's rare that you would need second accuracy,
anyhow. In the domain of problems that rely on civil time, I'd like to here
an argument about how something would go wrong if a timestamp was converted
to :60 rather than :61. It's a distinction without a difference.

Normally when you need accurate second or sub-second resolution, civil time
is not your immediate concern. No need to conflate the two
concepts--physical constant "second" and the "second" as a unit of
delineation of the civil day.

If I care about measuring metric seconds (e.g. in a more rigorously
scientific context), UTC is much too convoluted. TAI is tempting, but TAI is
also a lie: relativity tells us that there is no synchronized passage of
time, even between two points on the face of the earth. And in fact, this
limits the resolution of any shared timescale for earth. Which means there's
no avoiding thinking about what you actually need--TAI will usually be
sufficient, but you should also be able to justify it, rather than just
defaulting to TAI without consideration in the naive belief that it solves
all problems because of its tight coupling with the metric second.

Ultimately, just avoid converting between the systems. Use the same unit and
system consistently, and don't convert until the last possible moment, when
the loss in accuracy becomes least costly. Just like with floating point,
bignum arithmetic, etc.