257734 - Times shifted by timezone on re-exported events

Status: RESOLVED WORKSFORME

(Calendar :: Internal Components, defect)

Description

[Joe Bronkema]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803

When exporting a previously imported event, the time of the event is shifted 4
hours later (for me, in the US Eastern time zone).

Reproducible: Always
Steps to Reproduce:
1. Create a new event
2. Export the event
3. Delete the event from the calendar
4. Import the event.  It will appear at the correct time.
5. Export the event with a different file name.

Actual Results:  
The time of the event in the second exported file was 4 hours later than the
time in the first exported file.  This makes Calendar unusable for group
maintainership of a calendar file at a web site, since it's necessary to import
changes others have made, but further exports break the data.

Expected Results:  
The two files should have been identical.

Comment 1

[gekacheka]

Problem appears to be during import (parser).

In JS, imported event has event.start.utc == false even if it is a utc time that
ends with 'Z'.

(Parser requires C++ development.)

Comment 2

[Jonathan Hefner]

In the Central Standard Timezone (CST) the event time is pushed back 5 hours
(not 4).

Comment 3

[Joe Bronkema]

Attachment: Patch that fixes the symptoms

I don't fully understand the code at this point, so this patch may not be "the
right way" to solve this problem, but it does work for me.  I've only tested
with the latest CVS.  If someone can point out to me how to build the XPI, I'll
be happy to try it on 1.7.3 as well.

Comment 4

[Szelei Gabor]

*** Bug 287195 has been marked as a duplicate of this bug. ***

Comment 5

[Chin Jun Ngian]

I'm using version 0.8.3 and found bug when I import the ics file (exported from
iPlanet Calendar) into it. My Win XP's time zone is Kuala Lumpur (+8) but
Mozilla Calendar adds 9 hours to all the events.

Any fixes/ configuration I can do over Mozilla Calendar?

Comment 6

[Timothy Mercer]

Work around - waiting for fix in Mozilla Calendar:

My zidestore account is set to default to EST (EDT) time for scheduler.
My local environment is the same.
Thus I am -5 hours from GMT.
However, to get things to sync properly I have to create an event in Mozilla
Calendar / Sunbird which starts 4 hours ahead of when I want it really start,
publish entire calendar then reload the calendar.  Both zidestore and mozilla
are in sync.  If make changes to start or end time they stay in sync.

Example:

9:30 am meeting going until 11:45 am
Create new event with start time 13:30 ending 15:45 with appropriate other
details filled in
Publish entire calendar
Reload calendar
Now meeting is at 9:30 am.

So that's a hack which works for me.

Comment 7

[Timothy Mercer]

Strange behaviour:

Follow up to previous comment.  Created new accounts in zidestore/Ogo and set
timezone to EST as root.  Restarted all ogo-nhsd, ogo-webui, ogo-xmlrpcd, and
ogo-zidestore services.

Subscribed to these remote calendars.  Now the manual time shift is not
required.  Full day events work as well.

This was not the case when the ogo account was created with default MET timezone
and then changed by logging in as that user and changing the default to EST.

Anyway, the process that now works for me is as follows:

environment: ogo 1.0a zidestore 1.3 sunbird 0.2

log in as root to ogo
create new account
edit password for that account
change the timezone setting in the display pref of the account to EST.
repeat for as many accounts as required.

start sunbird
subscribe to the accounts required
all works well

all is good :)

Comment 8

[Joey Minta]

The original description of the bug is now worksforme in Sunbird 0.3a1.  I don't know the details of 'zidestore' mentioned in comment #6 and comment #7, but it should probably be handled in a separate bug, since there didn't seem to be any mention of export in the descriptions there.

Comment 9

[Marcia Knous [:marcia]]

Mass move of libxpical bugs to the Internal Components, per ctalbert.

Comment 10

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!