Re: 2017-03-06- UTC, TImeZone, DayLight Saving Shifts, Enconding

It's also worth considering how to avoid this:

https://www.wired.com/2007/04/school_forgets_/

Some time back I had a long conversation with some people from the power 
industry who were very interested in tzdist as they have significant 
problems when people get times wrong. Is the UTC time in the logs the 
real UTC or manufactured by a mis-set machine?

The time we live by is local time and incidents occur in that time 
frame. People assume they can log in UTC and then make the round trip 
back again at some arbitrary point in the future but it doesn't always 
work out so well. At least by storing the local time we are storing the 
time we want to see on that clock on the wall. If we also store the UTC 
offset and teh UTC we can index and sort and we also have a reference to 
show how we got from local to UTC at the time we did it - and we might 
have done it with incorrect timezone information.

> Any sane app stores in UTC ot UT with local time conversion done in the UI (with the UI making sure which local time is used is clear to the user).
Most of the problems we had in the past with timezone changes were a 
result of systems storing time only as UTC.
Again - what matters to the human trying to set up a meeting is the 
local times of each attendee. We convert all those - possibly differing 
- local times to UTC to ensure they agree but my regular meeting is at 
10am before and after DST transitions. When DST rules change what we end 
up changing is not the local time but the UTC.

On 3/18/17 14:41, Cyrus Daboo wrote:
> Hi Joe,
>
> --On March 18, 2017 at 8:01:06 AM -0700 Joe Touch <touch@isi.edu> wrote:
>
>>     - dates MAY use local time (UTC offset by the local time zone) for
>> applications that need to optimize for interacting with users
>
> Again I want to emphasize the calendaring and scheduling perspective 
> on this: because events may occur in the future, the calendaring 
> system will usually store the tuple of (local date-time, time zone 
> id). That way any changes to the time zone (e.g. DST rules) that occur 
> prior to the date will be properly taken into account. Also, if the 
> event is recurring, the usual expectation for users is that the local 
> time remains the same even when the DST (or even base time zone 
> offset) changes.
>
> Now, I am not sure whether your document should delve too deeply into 
> the calendaring and scheduling use case, but if it does then I 
> strongly suggest you cross-post discussion to the calsify mailing list 
> to get feedback from the c&s experts there.
>
> On the other hand, it may be sufficient to include a statement along 
> the lines of what I outlined above with a reference to a suitable c&s 
> spec. In fact, the Calendaring and Scheduling Consortium (CalConnect) 
> has been putting together a developer's guide which will include 
> discussion on recurrences, time zones, date/time formats etc: 
> <http://devguide.calconnect.org>, so maybe a reference to that would 
> also be appropriate.
>

Received on Sunday, 19 March 2017 03:40:45 UTC