Re: Predictable Internet Time

[Pete Resnick <[e-mail]>]

On 3 Jan 2017, at 12:55, Stewart Bryant wrote:

> On 03/01/2017 18:38, Cyrus Daboo wrote:
>> Hi Stewart,
>>
>> --On January 3, 2017 at 6:30:19 PM +0000 Stewart Bryant 
>> <[e-mail]> wrote:
>>
>>> Only the UI needs the TZ information, the machine can operate just 
>>> fine
>>> with any timescale. That is you present the time in local time, but
>>> operate in global time, and this is definitely an application that 
>>> will
>>> not care about leap seconds.
>>
>> No that simply does not work. Repeating events or alarms may not 
>> involve any UI at all, but the device may need to trigger those at a 
>> specific local time - that means time zone information has to be 
>> taken into account somewhere. This is a crucial fact of any 
>> calendaring and scheduling system that those of us who have been 
>> using iCalendar (RFC5545) fully appreciate.
>>
>
> Hi Cyrus,
>
> I think that depends on what you consider to be the infrastructure and 
> what you consider the application.

I think you and Cyrus are disagreeing about the definition of "UI". 
Maybe "application" is better. At some point in the flow of things, a 
system that is going to interact with humans, whether it presents a UI 
on a screen or turns on a beeper or flips a relay that starts a 
sprinkler system, is going to have to know the current civil time for 
the action it is performing, and that's going to have to be machine 
calculated.

> I would like to see the CPU clocks, and in particular  the time 
> transfer protocols just work on non-jumpy constant-duration-second 
> time since that has to scale from sub-femtoseconds to millennia with 
> sub-femtosecond accuracy without glitching and with unambiguous 
> duration measurements.
>
> If we distribute time in the infrastructure as  non-jumpy 
> constant-duration-second time , then the iCal system can surely do the 
> conversion to/from whatever format the human needs? Whether it talks 
> to itself in human time or machine time is for those of you that 
> design iCal to determine, but it sounds from what you say that it 
> talks to itself in human time. Whether it does the conversion from 
> machine time to human time, or whether the OS does it for outside the 
> scope of the point I am making.

Agree, but note the dependency: calendaring depends on some other entity 
to get the agreed universal time, and then it can do a conversion based 
on the time zone database information.

On 3 Jan 2017, at 12:51, Ted Lemon wrote:

> This is true, but any specific local time will always occur at a 
> specific universal time, so this isn't actually a problem.

Oh? Which specific universal time corresponds to 6pm local time on July 
1 2020 in Urbana, IL? It *will* occur at a specific universal time, but 
it does not *now* occur at a specific universal time, because Illinois 
can always change the law which tells you what "6pm local time on July 
1" means.

None of this is an unsolvable problem; we just need to be clear that at 
some point (and likely at many points), the computer is going to have to 
calculate a civil time from whatever agreed universal time you have, and 
it's not just "to present to the user at this particular moment".

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]