Subject: [Tzdist] UTC vs Local Time ...

From: Lester Caine <[email-masked]>
Date: Thu, 04 Sep 2014 10:15:31 +0100

As I indicated, I'd not dug too deeply into VTIMEZONE, but the flagging
up of the DTSTART being in local time has prompted me to review that.

There are a number of reasons for wanting to normalise timed events, but
mainly so that a correct comparison of order can be made. That an event
happens at sunrise just needs to establish when sunrise was, but the
advent of clocks introduced a level of chaos until there was some
agreement on what clocks should be synchronised to ( and I don't think
the French have ever forgiven the English? ;) )

While one is only handling time in a single timezone, things are a lot
easier to manage. PERSONALLY I find that once one has to deal with
clients spread across several zones with several different event
offsets, normalizing everything to UTC removes all the confusion.

I can see that VTIMEZONE works for it's targeted application, and as
long as each is handled in isolation running each in it's own local time
works, but once one needs to compare times between the two then a common
base is needed ... which is UTC ... so local times need to be normalized.

Now in terms of tzdist there is probably no need to be comparing data
between tzid's so handling each in isolation is not a problem. It is
only when event schedules move between zones that one needs a consistent
base, which is why we standardise on UTC under the hood. So I THINK all
I'm left with is that my use of the tz data is to convert a UTC time to
a local one, so my own tz object needs DTSTART as a UTC value rather
than local time.

SO - is iCalendar basically geared to managing 'local' time and
conversion to UTC is the exception, rather than providing a simple UTC
base and just providing local time as a display function?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 04 Sep 2014 09:45:52 -0400

Hi Lester,

> base and just providing local time as a display function?

Yes. The important thing to consider here is recurring events: humans (the 
primary target for iCalendar applications) often have repeating events at 
the same local time - lunch at 12 pm Monday-Friday. In the general case, 
you can't specify that in UTC because of the DST shifts that occur 
throughout a year - i.e., the event must be "anchored" to the local time 
value not the UTC value.

So iCalendar applications have to preserve local time+tzid in their 
internal representations, even if they actually do all their date-time 
arithmetic in UTC (having converted the local time based on the current 
tzid rules).

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Thu, 04 Sep 2014 16:21:52 +0100

On 04/09/14 14:45, Cyrus Daboo wrote:
> Yes. The important thing to consider here is recurring events: humans
> (the primary target for iCalendar applications) often have repeating
> events at the same local time - lunch at 12 pm Monday-Friday. In the
> general case, you can't specify that in UTC because of the DST shifts
> that occur throughout a year - i.e., the event must be "anchored" to the
> local time value not the UTC value.
> 

It's all just a matter 'practices'. Repeating events ARE just a 'time'
plus a pattern happening at a location, so when creating a new event,
you add a date and then the time for that location. I'm not doing
anything different to you on the room booking systems, except perhaps
viewing time+location in a different way. If the booking is for a video
link event the other participants may well have a different local time
and these are the problem ones at times when DST is changing. Planning
sees the local time + UTC time at the event location, but also local
times at remote locations. Room availability is displayed in 'UTC space'
so you can see if all sites have a room available at the same 'time' (
conference call meetings have the same availability problem )  and I'm
hoping to warn when a DST transition may cause a problem!

There is a lot to be said for killing off 'summer time'! Your 12pm
meeting may need to move when sharing between sites that don't change
their lunchtime :)