Re: Predictable Internet Time

[Harald Alvestrand <[e-mail]>]

Den 04. jan. 2017 00:32, skrev Philip Homburg:
>>> Time within the machine should be measured relative to its own temporal
>>> frame, but whenever we communicate with another machine we need to
>>> strive to be as close to UTC as possible - warts and all. Anything else
>>> - including and especially smearing - compromises *correct* behavior.
>>
>>
>> ?So you are for sticking with IPv4 as well?
>>
>> Nothing can ever change because the ITU is in charge...?
>>
>> ?People are only in charge as long as other people let them. ?
> 
> The 'obvious' solution is to make programmers, from operating systems all
> the way to application programmers, aware that there are different types
> of time.
> 
> Most programmers should already know that there is a difference between
> local time and UTC. We need to extend that a bit.
> 
> In particular, we need
> - a monotonic 'uptime' that can be used for local timers, etc. independent of
>   any external time source. 

FWIW, the W3C has switched to defining time inside a Web page in two
segments:
- Page load time, which is UTC-derived (POSIX time extended to
milliseconds), and can jump when the system clock is reset
- Events related to the page load time, which has floating-point
representation, and is guaranteed to be monotonic.

DOMHiResTimeStamp and related specs make for interesting reading
(although you'll feel at times like you're lost in a maze of twisty
little definitions, all different).

> - we need UTC. Civil time is UTC. We have no control over that. For many,
>   many years we know that leap seconds are a problem, but we are still stuck
>   with it. For many, many years we also know the daylight saving time is 
>   silly. But we have good solution for the timezone stuff.
> - we need a sensible time. There are many ways to define a sensible time,
>   but TAI is available, so let's use that. For me, sensible time includes
>   using SI seconds for keeping track of time.
> 
> The main thing is that, by and large, this is not a network problem. If a
> system uses TAI internally, it can use UTC for NTP, for SMTP, HTTP, etc. The
> only thing we may have to do at the network level is improve the availability
> of an up-to-date leap second list.
> 
> The big thing is, making sure that operating systems offer TAI as a first
> class citizen. Making sure that timers are set using MONOTONIC clocks and
> making sure that applications that use subsecond precision for time
> information internally use TAI and only convert to UTC for interacting
> with users.
> 
> Unfortunately, there doesn't seem to be an IETF equivalent for operating
> systems, so it will be completely random whether anything will happen in
> this area or not.
>