324804 - Missing timezone support for events (UTC is used instead of local timezone)

Status: RESOLVED DUPLICATE of bug 333717

(Calendar :: Internal Components, defect)

Description

[Akim Demaille]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060110 Debian/1.5.dfsg-4 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060110 Debian/1.5.dfsg-4 Firefox/1.5

The dates are always stored in UTC time (with an ending Z), regardless of
the current time zone.  This is really troublesome when the file is shared
with other iCal readers, such as Mac OSX's iCal.  The latter supports timezones,
and therefore displays the time wrt UTC, not wrt the current zone.  It is my
reading of the RFC that this is a correct rendering.  It would be much more
useful if the qualified time (with the timezone) could be used.  For instance,
(taken from the rfc):

Example: The following represents July 14, 1997, at 1:30 PM in New
   York City in each of the three time formats, using the "DTSTART"
   property.

     DTSTART:19970714T133000            ;Local time
     DTSTART:19970714T173000Z           ;UTC time
     DTSTART;TZID=US-Eastern:19970714T133000    ;Local time and time
                        ; zone reference

It is the third format that should be used, not the second.

Reproducible: Always

Steps to Reproduce:
1. Create an event
2. Read it with an iCal which timezone support is enabled
3. Or read the file by hand

Comment 1

[Stefan Sitter [:ssitter]]

What program do you used for testing? Sunbird, Lightning or Calendar Extension?
What version?

Comment 2

[Akim Demaille]

(In reply to comment #1)
> What program do you used for testing? Sunbird, Lightning or Calendar Extension?
> What version?

This authoring of the file is done with SunBird 0.2 (OSX).  I have tried to
use a more recent version (the 0.3 alpha 1), but it doesn't launch on my
machine (I don't know why).

I should make clearer my statement about the time zone in Mac iCal
When the event are reported by iCal OSX, it does properly changes the hour
to match the current time zone.  The problem is that it uses a +1h shift,
and Sunbird displays a +2 shift.  Maybe this is related to the fact that
in France we have a winter time during which we are UTC + 2, and summer
time during which we are at +1 (or is it the converse?  I can't remember).

I just checked: _that_ is the real problem: for a reccurent event, because
the date is stored in UTC instead of local time zone, it is subject to
changes of winter/summar time.  As a result, the recurring event is
properly displayed by SunBird that does not take this problem into account
(and PhPiCal doesn't either), but it is rendered incorrectly by Mac's iCal,
because it deals properly with winter/summer time.

So there are two issues here:
- using local time zone is more like what want people whose country have
  winter/summer time used
- recurring items in UTC time are incorrectly displayed always at the
  same time, regardless of the winter/summer time.

Comment 3

[Andrew N Dowden]

Attachment: testing of timezone settings for load, save, create (including cycling)

As can be seen in attached testing, this shows that Sunbird sometimes preserves time as local, and sometimes converts to UTC (or Zulu).

I agree that it is more useful to have events occur in local time (particularly to support events recurring in both Standard/Winter and Daylight/Summer time).

Comment 4

[Martin Schröder [:mschroeder]]

Maybe this is fixed by one of the patches for the DST & Timezone problems.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #2)
> So there are two issues here:
> - using local time zone is more like what want people whose country have
>   winter/summer time used

This is fixed in 0.3a1 and newer.

> - recurring items in UTC time are incorrectly displayed always at the
>   same time, regardless of the winter/summer time.

This is a dupe of 333717, and will be fixed in 0.3a2.
 



*** This bug has been marked as a duplicate of 333717 ***

Comment 6

[Reed Loden [:reed]]

The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!