Open Bug 520463 Opened 15 years ago Updated 2 years ago

Floating event converted to a different timezone causes assignment instead of convertion

Categories

(Calendar :: Internal Components, defect)

defect

Tracking

(Not tracked)

People

(Reporter: Fallen, Unassigned)

Details

I stumbled upon this while fixing bug 470430. The following code: let d = cal.createDateTime(); d.timezone = cal.floating(); let d2 = d.getInTimezone(cal.UTC()); merely assigns UTC as the timezone for d2, due to this code: http://hg.mozilla.org/comm-central/file/b65c6e52f0ad/calendar/base/src/calDateTime.cpp#l274 I think we should rather first assign the current default timezone, and *then* convert into the target timezone. This needs some investigation and probably eyeballing all callers.
Note that the future calStorageUpgraders.jsm (bug 470430) will contain code that does this manually, it should be removed when we fix this bug.
(In reply to comment #0) > I stumbled upon this while fixing bug 470430. The following code: > > > let d = cal.createDateTime(); > d.timezone = cal.floating(); > let d2 = d.getInTimezone(cal.UTC()); Philipp, could you please pass a pointer to this sequence, to get more context. Thanks.
Search for this bug# in the patch to bug 470430. The issue is that the date we are getting is in local time (floating) and set on an alarm. The alarm requires the trigger to be specified in UTC, so the date is converted. If the date was in floating timezone before, then UTC is merely assigned and the date is not really what is expected on conversion.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.