301484 - need a strategy for dealing with TZ changes on existing data

Status: RESOLVED DUPLICATE of bug 368121

(Calendar :: Internal Components, defect, P1)

Description

[Dan Mosedale (:dmosedale, :dmose)]

We'll need to make sure our applications cope reasonably for existing data when
timezone definitions change (as the US Congress is currently talking about doing
with Daylight Savings Time here).  This seems like something that would block a
1.0 release.

Comment 1

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Unfortunately, I do not have cycles to work on Calendar stuff these days (just as it's getting to the good part!), so I am a bad owner for these bugs.  To delete the tragically-large chunk of bugspam, search for gregorianabdication.

Comment 2

[Matthew (lilmatt) Willis]

Upping the priority of this.
The US daylight savings change is in March, and we need this fixed before then.

Comment 3

[Matthew (lilmatt) Willis]

We need to decide on the flow for events in a given timezone stored before that timezone's definition changed, but occurring after.

Assigning to dmose as part of the timezone work, but we should probably discuss this piece more.

FWIW: I set events in terms of what time they occur on my clock.  Lunch is always noon for me, regardless of Daylight Savings.  If that is the majority of a user's events, then those should just be migrated to the new timezone, leaving the datetime part of the DTSTART alone.

However, since we have no "set this event in another timezone" functionality in the event dialog, when a user needs to set something in terms of ANOTHER timezone (including UTC) they must do the UTC-to-myLocalTimezone conversion externally to Sb/Ln and then put that converted start date/time in.  Those cases by rights _should_ have been entered in Zulu time, but as I said, we don't have that capability exposed via the UI at the moment.  Those events should have their entire DTSTART re-evaluated.

I can't think of a good programmatic way to determine which of those two types an event is, short of looking to see if an event also changes dates/times when its VTIMEZONE changes from standard to daylight savings time.

Comment 4

[cmtalbert]

> FWIW: I set events in terms of what time they occur on my clock.  Lunch is
> always noon for me, regardless of Daylight Savings.  If that is the majority of
> a user's events, then those should just be migrated to the new timezone,
> leaving the datetime part of the DTSTART alone.
These will not change when the new timezone rules are put into place.  Noon in America/New_York timezone will still be noon in America/New_York timezone after the change.  It is just like when you go into/out of DST, your lunch date does not change if that lunch date is in your timezone.

Likewise, floating events (events with no timezone specified) would never be affected by timezone changes or timezone definition updates.

The real issue is when the user enters events that are not in his usual timezone, as you allude to below.
> 
> However, since we have no "set this event in another timezone" functionality in
> the event dialog, when a user needs to set something in terms of ANOTHER
> timezone (including UTC) they must do the UTC-to-myLocalTimezone conversion
> externally to Sb/Ln and then put that converted start date/time in.  Those
> cases by rights _should_ have been entered in Zulu time, but as I said, we
> don't have that capability exposed via the UI at the moment.  Those events
> should have their entire DTSTART re-evaluated.
> 
Because there has never been an easy way for the user to enter an event NOT in their timezone, we have to assume that the events in the calendar store are in the timezone as specified in the calendar store. That means that if they input a UTC event into their calendar and stored it with a timezone of America/New_York, then when we upgrade we will have to assume that this was originally an America/New_York event.  I think if we try to guess what timezone the user "really meant" then we are just going to dig ourselves into a hole, and probably mess things up worse.

** We desperately need the ability to set a timezone on the event dialog. **

Comment 5

[Matthew (lilmatt) Willis]

(In reply to comment #4)
> These will not change when the new timezone rules are put into place.  Noon in
> America/New_York timezone will still be noon in America/New_York timezone after
> the change.

Keep in mind that we're not dealing with _replacing_ America/New_York.  We'll be adding /mozilla.org/200701nn_1/America/New_York and needing to migrate events using /mozilla.org/20050126_1/America/New_York TO the new version.

Comment 6

[Matthew (lilmatt) Willis]

Duping