Re: [art] Predictable Internet Time

[Nico Williams <[e-mail]>]

On Tue, Mar 28, 2017 at 02:40:07PM -0700, Joe Touch wrote:
> On 3/28/2017 10:39 AM, Nico Williams wrote:
> > On Tue, Jan 03, 2017 at 06:35:03PM +0000, Stewart Bryant wrote:
> >> Yes, the system should use a leap-second-free constant-duration-seconds time
> >> for everything. It is only humans that need the variable jumpy version of
> >> time presented to them, and that is a UI issue.
> > I don't think that's quite right.
> >
> > Unix time is canonically a count of seconds since an epoch and admits no
> > leap seconds. 
> 
> Unix time also uses a completely different definition of a "second" than
> UTC.

Did I.. say otherwise?

> There is no simple conversion between Unix time and UTC. Conversion
> requires accurate assessment of the local Unix clock vs SI to determine
> a rate conversion as well as knowing the table of leap seconds since the
> Unix epoch.

You're complicating things.  Forget the local clock.  To convert a time_t
value to UTC requires just a list of leap seconds (and some arithmetic).

There's no need to assess the quality of the local clock or anything of
the sort.

> > ...
> > It's all about data typing. 
> 
> That is certainly one problem, but not the only one.

It's really the main one, IMO.  In any case, smearing seems very wrong:
you end up with more problems because you go from roughly two kinds of
time (UTC vs TAI-ish) to three kinds of time (UTC vs TAI-ish vs the new
thing).  If people had a hard time interoperating with two kinds of
time, imagine how it would be with THREE kinds of time.  And if the
smearing formula ever needs updating, then we'd be in trouble.  (Earth's
rotation normally _slows_ over time, but the 2004 earthquake _sped up_
Earth's rotation.  A few big ones and we might need negative leap
seconds.  PIT's formula can't predict these events.)

Just specify, in each protocol, the use of TAI (x)or UTC.  Done.

Nico
--