305432 - setting nativeTime sets timezone to UTC

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[gekacheka]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050820 CalendarItemDialog/0.1.0 Mozilla Sunbird/0.2+

setting nativeTime sets timezone to UTC
http://lxr.mozilla.org/mozilla/source/calendar/base/src/calDateTime.cpp#215

But interface says it should use the current timezone.
  "If nativeTime is set, the given UTC PRTime value is exploded into
   year/month/etc, taking into account the timezone setting."
http://lxr.mozilla.org/mozilla/source/calendar/base/public/calIDateTime.idl#72

Reproducible: Always




Workaround:  
  1. save old timezone: 
      tz = calDateTime.timezone.
  2. set nativeTime:  
      calDateTime.nativeTime = n;
      calDateTime.normalize();
  3. construct another calDateTime by calling 
      calDateTime = calDateTime.getInTimezone(tz);

Comment 1

[Mike Shaver (:shaver emeritus)]

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

[Bas van den Bosch]

Is this bug still valid?

Comment 3

[:Hb]

Yes. But it is questionable if it should be fixed. It gives an easy way to delete DT/DST information from a date, as needed in bug 402841 and in bug 416206 for calculating offsets with discrete days. 

Changing the interface description to it's current behaviour would preserve the current code which uses nativeTime. Creating features out of unsolved bugs is generally bad so please examine this issue in detail here.

Comment 4

[cmtalbert]

Daniel, what's your opinion on this issue?  Can we resolve this bug as WFM or should we actually fix it, or simply change the description in the interface?

Comment 5

[Daniel Boelzle [:dbo]]

IMO we should just document the current behavior, i.e. that it's enforcing UTC. BTW: What's meant with "the current timezone"? calendarDefaultTimezone() or the timezone that is already set at the object?

Comment 6

[gekacheka]

(In reply to comment #5)
> BTW: What's meant with "the current timezone"? calendarDefaultTimezone() or the
> timezone that is already set at the object?
> 
The timezone setting of the datetime object.

Comment 7

[Daniel Boelzle [:dbo]]

Attachment: document the current usage

I think we should just properly document the current usage.

Comment 8

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 345162 [details] [diff] [review]
document the current usage

r=philipp

Comment 9

[Daniel Boelzle [:dbo]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/5893a5dcb678>

-> FIXED

Comment 10

[Philipp Kewisch [:Fallen][📱📆]]

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".