[LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

Rob Seaman seaman at lpl.arizona.edu
Wed Jan 16 09:06:31 EST 2019


On 1/15/19 11:36 PM, Warner Losh wrote:

> It's a fundamental flaw of UTC. There are other ways to implement
> something akin to UTC that implements some form of mean solar time
> that's not an observational calendar.

If either part of this is consensus, then a proposal to redefine UTC
after a certain date is also fundamentally flawed. Redefinition cannot
simplify a standard - any standard - it can only make it more complex,
e.g.: "before the specified date, the standard behaves one way, after it
behaves another way". Timekeeping has many retroactive use cases,
including all those intervals people mention. What about instances that
cross the redefinition boundary and the two end points have two
different meanings? The engineering requirements to support the original
definition never go away.

The vast majority of timestamps trace back to GPS and other GNSS-derived
values, even if GPS is deemed an unclean standard by the lab-coated
acolytes of the atomic clocks (https://bit.ly/2MeCcGp). Or TAI itself is
already available - indeed, UTC provides TAI as well as a prediction of
UT1. Or simply define a new unsegmented TI timescale as was the
consensus at the Torino meeting in 2003. Redefining UTC would be a
colossal blunder. The time wasted over the past two decades on this
fool's errand could have been better spent standing up a new TI
infrastructure, or simply writing better documentation.

That said, nothing about the current discussion bears on the definition
of UTC, only on how best to handle conversions.

Rob


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20190116/64232d2a/attachment.html>


More information about the LEAPSECS mailing list