Re: Predictable Internet Time

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 
> > <stewart(_dot_)bryant(_at_)gmail(_dot_)com> 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. - +1 (858)651-4478