+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 <cyrus@xxxxxxxxxx> wrote:
Hi Ted,
--On January 3, 2017 at 1:51:54 PM -0500 Ted Lemon <mellon@xxxxxxxxx> 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