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)
Calendar
Internal Components
Tracking
(Not tracked)
NEW
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.
Reporter | ||
Comment 1•15 years ago
|
||
Note that the future calStorageUpgraders.jsm (bug 470430) will contain code that does this manually, it should be removed when we fix this bug.
Comment 2•15 years ago
|
||
(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.
Reporter | ||
Comment 3•15 years ago
|
||
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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•