Re: Predictable Internet Time

[Phillip Hallam-Baker <[e-mail]>]

+1

Case in point, the time displayed on my Honda Oddy does not correct for
daylight savings correctly because some pimple brain decided to vary the
date of the switchover and there is no way to update the firmware without
spending stupid amounts of money to do so.

This is the sort of thing I would like to be able to avoid in IoT. The
problem being that to do so requires vendors to think about problems as
something other than an excuse to sell a 'pro' version or updates.

One of the things that is really odd about time as a social construct is
just how easy it is to tamper with it. And 95% of the reason people do
tamper has nothing to do with purported benefits, it is to show that they
can.

When the UK went on to permanent summer time for a brief period, accidents
shot up in the mornings which is the only effect that can be attributed to
the change. The accident rate was reduced by more in the evenings but
subsequent analysis showed that the effect was due to drink driving being
banned at the same time.

The definition of time has always been driven by technology, Railway time
is the reason we have time zones in the first place. Solar noon at
Greenwich varies by +/- 15 minutes over the year.


Not being able to predict with accuracy when a future time expressed in
civil time will occur is a problem.



On Tue, Jan 3, 2017 at 2:54 PM, Cyrus Daboo <[e-mail]> wrote:

> Hi Ted,
>
> --On January 3, 2017 at 1:51:54 PM -0500 Ted Lemon <[e-mail]>
> wrote:
>
> 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.
>>>
>>
>> This is true, but any specific local time will always occur at a specific
>> universal time, so this isn't actually a problem.
>>
>
> No! That is not true because a future local time is not guaranteed to be
> at a specific universal time because local government can change their time
> zone (or more likely) their daylight savings time transition at any time
> between now and said future time. i.e., you cannot "pre-cache" all the
> local time -> UTC mappings for a future recurring event and then just use
> the UTC values, because the time zone definition may change.
>
> --
> Cyrus Daboo
>
>