Re: [art] Predictable Internet Time

[Nico Williams <[e-mail]>]

On Tue, Mar 28, 2017 at 11:47:20AM -0700, Joe Touch wrote:
> On 3/28/2017 11:43 AM, Nico Williams wrote:
> > On Tue, Mar 28, 2017 at 11:21:02AM -0700, Joe Touch wrote:
> >> On 3/28/2017 8:13 AM, Tony Finch wrote:
> >>>> - One thing I'd like to add is 'uptime' or more general, monotonic time.
> >>> An interesting discussion re. compatible APIs for elapsed time:
> >>> https://github.com/golang/proposal/blob/master/design/12914-monotonic.md
> >> This is another example of the confusion that results when the time
> >> scale is not clearly indicated or defined. Having Go read the "system
> >> wall clock" is the source of the problem, and this doc explains a
> >> variety of solutions.
> > Better data types -and strong typing- are needed:
>
> Unix defines only POSIX time right now, FWIW.

POSIX defines POSIX time.  Unix and Unix-like systems use it.

(Nothing stops any Unix-like OS from including extensions.)

> AFAICT, wouldn't specing Unix interfaces to the different times below be
> out of scope for the IETF?

Yes and no.

First, the IETF has and does specify some APIs.  (BSD sockets bindings
for IPv6, GSS-API, and various others.)

Second, the IETF could define abstract APIs but refrain from specifying
C bindings for APIs and recommend to the Open Group and others that they
standardize those based on the abstract APIs.  (GSS-API, for example,
defines both, abstract and programming-language-specific bindings.)

Regardless, how could we address our time issues without specifying what
amounts to.. type conversions?  That's an API by whatever name you wish
to call it.  Best call it an API, define "types" and "type conversions"
or "functions" that do the same.

Obviously, for leap second smearing, besides an API there is also
behavior (smearing).

There's some difficulty with typing smeared time in that a smeared time
would be closer to UTC than POSIX time, but *pretending to be POSIX
time*.  Which makes it difficult to have strong typing (which you get
becomes a run-time matter!), but makes it easy to inject the new type in
existing object code.

But it may still be necessary to convert smeared time (when you know
that's what it is) to other time forms, and there has to be a canonical,
reproduceable, non-host-dependent way to do it, else you end up with a
synchronization problem.

Nico
--