Closed Bug 368709 Opened 13 years ago Closed 13 years ago

[0.3.1] Timezone information is being ignored or destroyed

Categories

(Calendar :: Internal Components, defect, critical)

Sunbird 0.3
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cmtalbert, Assigned: mattwillis)

References

Details

(Whiteboard: [verified0.3.1])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20070130 Calendar/0.3.1pre

When creating an event in 0.3.1 sunbird, it appears that timezone information is being destroyed or at least, is not being saved.  It does not appear that this is  was a bug on 0.3 itself.

Reproducible: Always

Steps to Reproduce:
There are different steps to reproduce the problem, on windows you just have to start the application. On Mac you have to change the timezone once.
Windows Steps:
1. Install 0.3.1 into clean profile
2. Create a calendar
3. Create an event at 9AM 
4. Check the view -- event is now at 9AM + (your UTC offset)
5. Go to File->Export and export the calendar to ICS
6. Open that ICS in a text editor

On Mac, I was able to do the same but, first I had to change my timezone to Europe/Berlin, then restart sunbird. After that timezone change, the above steps were readily reproducible.

Note that these steps do not reproduce the same behavior on the 0.3 release.
Actual Results:  
The events in views are displayed at their time + UTC offset.
The event is exported as floating time (no timezone information in ICS).


Expected Results:  
The events would be expressed in local time in the views -- relative to the selected timezone or guessed timezone in preferences.

The events would be exported with proper timezone information.

This is a critical error in a "timezone maintenance release".
Version: unspecified → Sunbird 0.3
Flags: blocking-calendar0.3.1?
Blocks: 321653
Flags: blocking-calendar0.3.1? → blocking-calendar0.3.1+
Duplicate of this bug: 368704
Comparisons expect a trailing slash in the /mozilla.org/yyyymmdd_1/ prefix, and we don't use one when making tzdata.c.  We need to add one to the gTzIdPrefix.
Assignee: nobody → lilmatt
Status: NEW → ASSIGNED
Attachment #253362 - Flags: second-review?(mvl)
Attachment #253362 - Flags: first-review?(ctalbert.moz)
Comment on attachment 253362 [details] [diff] [review]
Comparisons are expecting a trailing slash, which we're missing.

I have tested this change on 0.3.1 and it works for importing an ICS from a timezone that was deleted from the 2007 Olsen series and for old 2005 timezones that still exist in the 2007 Series.  Other timezone issues previously noted with 0.3.1 also seem to be fixed.
Attachment #253362 - Flags: first-review?(ctalbert.moz) → first-review+
Comment on attachment 253362 [details] [diff] [review]
Comparisons are expecting a trailing slash, which we're missing.

r2=mvl
Attachment #253362 - Flags: second-review?(mvl) → second-review+
Patch checked in on MOZILLA_1_8_BRANCH, SUNBIRD_0_3_BRANCH, LIGHTNING_0_3_BRANCH, and trunk.

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [fixed0.3.1]
VERIFIED on 0.3.1 -- Lightning: 2007020304 (Thunderbird: version 2 beta 2
(20070131)) AND on Sunbird: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
en-US; rv:1.9a1) Gecko/20070203 Sunbird/0.3.1

(needs Verifying on 0.5)
Living in Germany I had created events from within Lightning (no import). It seems that all events are starting two hours earlier now that I updated to the current nightly. Is this expected behaviour?
Whiteboard: [fixed0.3.1] → [verified0.3.1]
Navid, this is not expected.  Are you using the latest 0.3.1 nightly? What type of calendar are you using (iCalendar, CalDav, Local, WCAP...).  You created the events as new events with the 0.3.1 build?
Navid, I also need to know what OS you are running, what timezones the events you are creating are in (are they in central europe timezone)? Please let us know by February 6, 2007, because we need to get this resolved quickly if there are still issues. 
You need to log in before you can comment on or make changes to this bug.