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.bryant@xxxxxxxxx> 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