355449 - Timezone adjustment miscalculated when reloading or opening Lightning/Sunbird

Status: RESOLVED DUPLICATE of bug 314339

(Calendar :: Provider: ICS/WebDAV, defect)

Description

[Rich]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Sunbird & Lightning 0.3 RC1 

Entering the event within either program will send correct time for "america/los angeles" timezone to remote calendar, however upon reloading of a Remote calendar to include exit of program and restart will yield incorrect time due to what looks like the time zone not being used from from settings and results in display within lightning or sunbird showing the time - 8 hours (GMT -8 for Los angeles).  When time is entered it will send correct info about event to Remote calendar (WebCalendar 1.1.1).  Reload and again the time is shifted -8 hours.  Webcalendar continues to show correct time even when publishing and does not change the Webcalendar even though display is still GMT -8.  If you edit the event with or without changing the data then publish from either Lightning or Sunbird it will then send the data with the incorrect time and updates the WebCalendar to the wrongly displayed time.  


Reproducible: Always

Steps to Reproduce:
1. Normal usage of program either upon startup or reload of remote calendars yields the same incorrect timezone adjustment results.
2.
3.

Actual Results:  
Work Around:  I have set lightning and sunbird to Europe/London (GMT) and whether the event is entered on the client side or via the web the events will now show as the correct time of the day.  WebCalendar's systems settings for time zone were were adjusted to europe/london and back to america/los angeles timezone and either way as long as Lighting and sunbird are setup for europe/lond timezone then the timezone shift is avoided.

Comment 1

[Matthew (lilmatt) Willis]

When using America/Los_Angeles in Sunbird/Lightning, could you attach an ICS export from Webcalendar?

This sounds like Webcalendar may be converting the mozilla.org timezone to a non-mozilla one or something similar.

Comment 2

[Rich]

Hmmm looks like the workaround doesn't work.  Darn.  It seems that the time is now being displayed with +8 hours.  

Comment 3

[Rich]

Hey Matt, 

How do i send you an ICS export?  From webcalendar itself or from with Lightning for that remote calendar???

Rich

Comment 4

[Rich]

OK this is exported from within Lightning:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VEVENT
CREATED:20061004T235329Z
LAST-MODIFIED:20061004T235329Z
DTSTAMP:20061004T235320Z
UID:-CALENDAR-SCOTTBUNCH-COM-RICH-0000000316
SUMMARY:Uhh Ohh the 13th
STATUS:CONFIRMED
CLASS:PUBLIC
DTSTART:19700101T000000Z
DTEND:19700101T000000Z
DESCRIPTION:Uhh Ohh the 13th
END:VEVENT
BEGIN:VEVENT
CREATED:20061004T235329Z
LAST-MODIFIED:20061004T235329Z
DTSTAMP:20061004T235320Z
UID:4299a358-1dd2-11b2-a228-d062222b6f88
SUMMARY:Thanksgiving Day
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=4TH
DTSTART;VALUE=DATE:20001123
DTEND;VALUE=DATE:20001124
DESCRIPTION:Thanksgiving Day
END:VEVENT
BEGIN:VEVENT
CREATED:20061004T235329Z
LAST-MODIFIED:20061004T235329Z
DTSTAMP:20061004T235320Z
UID:
 5562F318-1E62-11D7-B51B-000393BCF7D2-C037CD25-44EC-4513-A6CD-5FCB259248D5  
SUMMARY:Halloween
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=YEARLY;INTERVAL=1
DTSTART;VALUE=DATE:20031031
DTEND;VALUE=DATE:20031101
DESCRIPTION:Halloween
END:VEVENT
BEGIN:VEVENT
CREATED:20061004T235329Z
LAST-MODIFIED:20061004T235329Z
DTSTAMP:20061004T235320Z
UID:-CALENDAR-SCOTTBUNCH-COM-RICH-0000000126
SUMMARY:Court
STATUS:CONFIRMED
CLASS:PRIVATE
DTSTART:20060928T080000Z
DTEND:20060928T100000Z
DESCRIPTION:Greg pretrial hearing
END:VEVENT
BEGIN:VEVENT
CREATED:20061004T235329Z
LAST-MODIFIED:20061004T235329Z
DTSTAMP:20061004T235320Z
UID:-CALENDAR-SCOTTBUNCH-COM-RICH-0000000315
SUMMARY:Test on Web for Rich
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=DAILY;COUNT=8;INTERVAL=2;BYDAY=MO,TU,WE,TH,FR
DTSTART:20061006T130000Z
DTEND:20061006T130000Z
DESCRIPTION:Test on Web for Rich 2pm
END:VEVENT
END:VCALENDAR

Comment 5

[Rich]

Here is the export from Webcalendar:

BEGIN:VCALENDAR
X-WR-CALNAME;VALUE=TEXT:rich
PRODID:-//WebCalendar-v1.1.1
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
UID:-CALENDAR-SCOTTBUNCH-COM-RICH-0000000304
SUMMARY:Family Home Evening
DESCRIPTION:Family Home Evening
LOCATION:Home
CLASS:PUBLIC
STATUS:CONFIRMED
DTSTART;VALUE=DATETIME:20061002T000000
DTSTAMP:20061005T000234Z
RRULE:FREQ=WEEKLY;BYDAY=MO
END:VEVENT
BEGIN:VEVENT
UID:-CALENDAR-SCOTTBUNCH-COM-RICH-0000000315
SUMMARY:Test on Web for Rich
DESCRIPTION:Test on Web for Rich 2pm
CLASS:PUBLIC
STATUS:CONFIRMED
DTSTART:20061006T130000Z
DTSTAMP:20061005T000234Z
DTEND:20061006T130000Z
RRULE:FREQ=DAILY;INTERVAL=2;BYDAY=MO,TU,WE,TH,FR;COUNT=8
END:VEVENT
END:VCALENDAR

Comment 6

[Smokie Darling]

I seem to be having the same problem, only I'm creating events from Google Calendar and exporting them to an .ics file.  I find that Sunbird is too screwy for my tastes, and I'm forced to use Google until it gets better.

User agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070118 Calendar/0.6a1

Steps to reproduce (for me):
1. Start with clean profile
2. Make complex calendar in Google (I can attach mine if needed)
3. Download .ics file
4. Import .ics file into Sunbird. Times are correct.
5. Close Sunbird.
6. Reopen Sunbird. Times are now offset by +6 hours.

Also seems like <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=333717">bug 333717</a> and <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=333664">bug 333664</a> might be related.

Comment 7

[Stefan Sitter [:ssitter]]

(In reply to comment #6)
Smokie Darling, 
currently Sunbird/Lightning can't handle non-mozilla timezone definitions correct, that means timezone information is lost after restart -> Bug 314339.

Comment 8

[cmtalbert]

These ICS files from Rich do currently work.  I think the issue here is that webcalendar is/was taking our timezone offset and converting to UTC, but leaving the timezone specifier in.  Then we'd try to convert it when we got it back, and webcalendar would convert it, and so on.  Webcalendar used to store only offsets, and not true timezone definitions (which is the current issue with google calendar too). 

We need some interop testing with a WebCalendar backend, but I'm going to mark this bug as a dupe to bug 314339, since the remaining timezone issues that exist will be handled there.