188095 - Z on the end of time stamp ignored. time zone misinterpreted.

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[ron]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021218 Debian/1.2.1-4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021218 Debian/1.2.1-4

timestamps such as DTSTART:20030115T030000Z which are downloaded to the calendar
are misinterpreted. the calendar thinks the above time is 3am on jan 15 but it
ignores the fact that i am in PST so this time should really be 7pm jan 14th.
this problem can be corrected by grabbing my local time and recalculating the
event time accordingly.

Reproducible: Always

Steps to Reproduce:
1. create event in moz cal (time=7pm)
2. upload it to phpical 
3. download the event back to moz cal. 

Actual Results:  
1. the time is still 7pm on the server but in zulu time
2. the time is 3am the day before after downloading it to moz cal

Expected Results:  
the time should be 7pm on the moz cal.

i was told by miked to assign this to [e-mail] but i don't see
anywhere to assign it.

Comment 1

[Brant Gurganus]

reassigning per report

Comment 2

[Mike Potter]

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

Comment 3

[steve farrell]

Line 1931 in oeICalEventImpl.cpp is suspicious

m_start->m_datetime = icalproperty_get_dtstart( prop );         
m_start->m_datetime.is_utc = false; // throws out interpretation of the "Z"

Comment 4

[Mike Potter]

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

Comment 5

[Torsten]

The 'Z' for DTSTART is ignored but the time for DTEND is correctly converted
into local time. 
This behaviour seems to go with additionial comment #3 where only
icalproperty_get_dtstart is mentioned.
                                       

Comment 6

[Ray B Foulkes]

I can confirm that the time zone correction ON THE WAY IN from ICS for DTSTART
is ignored. You cannot even do a round trip through ICS correctly. I am in CET.
I create a one hour event. On the way out the ICS file is correct showing a one
hour event in UTC. I then delete the event. Re-import and it is now a 3 hour
event with the start time fail to be translated. Sorry I cannot help fix the
bug, but the test is easy.

Comment 7

[Ray B Foulkes]

Can someone help. I would like to look at the source. I cannot find in the LXR
browser under Mozilla the file oeICalEventImpl.cpp, can someone give me a hint
(apart from setting up CVS and trying to book it out), the URL where I can
browse it?

Comment 8

[Mostafa Hosseini]

See http://lxr.mozilla.org/mozilla/source/calendar/libxpical/

Comment 9

[Ray B Foulkes]

Thanks Mostafa, I admit after hours searching, DTSTART and DTEND look symmetric!
Some experiments:
1. The Z on the time zone is being interpreted somewhere, replace with illegal P
and chaos results
2. Remove Z from DTEND and the event end time is correctly set as local.
Therefore Z IS being interpreted correctly on DTEND.
3. Change order of DTSTART and DTEND in input file - unsurprisingly no effect.
4. I am not convinced by comment number 3 because further down in startdate,
SetTimeInTimezone is called which, if there is a UTC indicator, is supposed to
convert from UTC to local time, so m_start should NOT be in UTC (the code seems
correct).
5. Note that 16593 refers to the same problem, but is really different topic.
I have no means of building the calendar. Is there a binary available built with
ICAL_DEBUG_ALL in  oeDateTimeImpl.cpp turned on? (I will work patiently through
the traces to see if I can figure out where the problem is).

Comment 10

[Mostafa Hosseini]

Thanks for the detailed information and the pointers Ray.It helped a lot.
Support for UTC datetime values has now been added to CVS. The change will
appear in an XPI dated later than today.
Changes:
http://bonsai.mozilla.org/cvsview2.cgi?file=oeICalEventImpl.cpp&subdir=mozilla/calendar/libxpical&command=DIFF_FRAMESET&rev1=1.68&rev2=1.69

Note: Timezones still need to be supported on the front end to enable proper
editing of events ( see bug 165963 ), however with this fix, displaying events
with UTC datetime values should be working.

Comment 11

[Mostafa Hosseini]

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

Comment 12

[Roland Mainz]

It looks this checkin broke the "nebiros" tinderbox on Seamonkey-Ports
(http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Ports) - see
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Ports/1051224900.28691.gz

Comment 13

[Reed Loden [:reed]]

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