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

Hi nicolas,

--On March 8, 2017 at 2:17:53 PM +0100 nicolas.mailhot@laposte.net wrote:

>> 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).
>
>| In general, this is extremely important and correct. But there's an
>| exception. If e.g. a meeting is at 3pm local time in some location,
>| independent of daylight saving time, then you better save that fact as
>| such, without trying to use UTC and friends.
>
> Even then you absolutely do want to save it in UTC (and display it in
> local time), otherwise you'll have problems as soon as you invite someone
> who usually lives in another country. Because *his* user agent will
> interpret local time as *his* local time, the user or the software will
> then attempt to convert to *your* local time, and botch everything up.

Calendaring and Scheduling applications based on the IETF iCalendar 
standard (RFC5545) typically do use localtime+timezone-id in their 
representation because they have to deal with recurring events that may 
well span daylight saving time boundaries, and thus do not occur at the 
same UTC time throughout a year. This is a well established practice, and 
yes there are sometimes problems getting it implemented correctly and 
dealing with cases such as attendees in different time zones. But clients 
usually get this right provided they all have the correct, up to date, time 
zone data available to them. Dealing with the later situation was one of 
the main reasons for the IETF's time zone distribution protocol (RFC7808) 
which leverages the IANA time zone database.

-- 
Cyrus Daboo

Received on Wednesday, 8 March 2017 14:48:29 UTC