165963 - views should default to pegging events to default timezone

Status: VERIFIED FIXED

(Calendar :: General, defect)

Description

[Lester]

I am starting a company where I work in Canada, and my Partner works in Korea. 
We want to share a calendar on a server with the data stored as, say Zulu time
(Greenwich Mean Time).  We should be able to view this data as any time zone in
the world.  Because we cross the international date line, the same data when
viewed as Canadian time will be on different dates as when viewed as Korean
time.  This feature would really help with scheduling.

That's my itch...  ...I wish I could scratch it, but I'm not good enough!

Comment 1

[Mike Potter]

What you should be able to do is specify which timezone you want to store your
calendar data in, and then what time zone you are in, and the calendar should
calculate everything out for you.
cc: [e-mail] since this will require some backend work.

Comment 2

[Mike Potter]

This is for Mostafa.

Comment 3

[Brant Gurganus]

Default QA Contact for Calendar has changed.  If you wish to remain the QA
contact for this bug, feel free to change it back.

Comment 4

[Mike Potter]

Moving this to normal status. If we're publishing calendars, then we need this
feature.

Comment 5

[Ron Thigpen]

Also, event and calendar .ics files should represent the local timezone choice

See:
Section 4.8.3 Time Zone Component Properties [Page 96]
<ftp://ftp.ietf.org/rfc/rfc2445.txt>,
which defines Time Zone related data entities for the vCal file format. 

A block such as this would contain this data:

BEGIN:VTIMEZONE
TZID:US-Eastern
TZOFFSETFROM:-0500
END:VTIMEZONE 

Comment 6

[Mostafa Hosseini]

The backend now supports very basic support for setting the timezone for the
start date and end date.To do so instead of calling setTime() to set the value
for these fields the setTimeInTimezone( time, tzid ) function should be called.
The first argument is the time in milliseconds as usual and the second argument
is the unique id of a timezone definition. Currently a basic set of timezone
definitions have been implemented. The format of their tzid is
/Mozilla.org/BasicTimezones/NH-GMT-12:00 to NH-GMT+12:00 with 00:30 steps. This
set includes the daylight saving time info for the northern hemisphere( hence
the "NH" ) for most locations.
Although the timezone can be set as mentioned for date values, the values and
all calculations involving them will reflect the converted time for the host
machine's timezone setting. Therefore here are the steps necessary to be taken
at the frontend:
1) Set the time with the setTimeInTimezone function when a different timezone is
needed
2) Calculate and show actual (non-converted) values when editing an event that
has a tzid set for one of its date values.
Notes:
-The .tzID attribute shows whether a startdate or enddate has a timezone set.
-When no timezone is set the value is assumed to be "floating" ( based on the
localtime of the machine ).
-Maybe we could have an option in the future to use a different timezone for
rendering the display than the local machine's timezone.
-Recurring events will most likely have problems because their recurrence rule
is not taking into consideration any timezone setting.

Comment 7

[Ron Thigpen]

It appears as if the default for events continues to be a "floating" state,
rather than having an explicit timezone (TZ) set.  

I wonder how this will affect mobile users who move a laptop system between TZs.
 If they reset their system default to a TXwith a different GMT offset, will the
floating calendar events be correctly represented, or will they be shifted to
the same time of day in the new TZ?  

This same shift would also occur in shared calendars and events when sync'd
against a server copy to two or more clients in different TZs.

To prevent such shifts it would seem to be necessary to record the originating
TZ for all events so that the local time could be calculated against it.  Any UI
renderings of events would also always be compared against the current system
local TZ.  Calendars that are uploaded to servers for sharing would also need to
be include either calendar-wide or event-specific TZs, so it would seem to make
sense to always record them. 

If all of this is indeed the cases, perhaps we should consider deprecating
setTime() altogether in favor of setTimeInTimezone().  This might seem like a
lot of effort now, but wouldn't it set the table for a great deal of future
functionality?

Comment 8

[Steve Garcia]

Attachment: A sample ical file with UTC start and end

Importing this file will cause the start time to display as if it were later
than the end time.  Start time appears to act like it were 'floating' time, end
time correctly handles time zone.

Comment 9

[Steve Garcia]

I attached an ICS file with less explanation than I intended.  When both start
and end times in the event are specified as UTC time, Calendar imports them but
only correctly handles the end time.

 DTSTART:20030418T164500Z
 DTEND:20030418T170000Z

These entries result in a user display of 
 Start: 4:45PM
 End:  10:00AM

I wasn't sure if this should have been entered as a new bug or as a continuation
of this one.  It looke like this one might cover it, so I took a chance.

Comment 10

[Grant Fengstad]

Should not Mozilla Calendar automatically calculate the display of the events
given a user preference of which timezone is selected for that user?

If I have an event defined as:

BEGIN:VEVENT
UID:3e53af1b00000374000014f7000032ac
DTSTAMP:20030428T192509Z
SUMMARY:Security Architecture Meeting
DTSTART:20021219T160000Z
DTEND:20021219T170000Z
CREATED:20030219T162147Z
LAST-MODIFIED:20030417T020006Z
PRIORITY:0
SEQUENCE:0
DESCRIPTION:514-422-4902
CLASS:PUBLIC
ORGANIZER;SENT-BY="[e-mail]"
 ;X-NSCP-ORGANIZER-UID=AC005757
 :AC005757
STATUS:CONFIRMED
TRANSP:OPAQUE
X-NSCP-ORIGINAL-DTSTART:20021219T160000Z
X-NSCP-LANGUAGE:en
X-NSCP-DTSTART-TZID:America/New_York
X-NSCP-TOMBSTONE:0
X-NSCP-ONGOING:0
X-NSCP-ORGANIZER-EMAIL:[e-mail]
X-NSCP-GSE-COMPONENT-STATE;X-NSCP-GSE-COMMENT="PUBLISH-COMPLETED":65538
END:VEVENT

Should not Mozilla be able to translate the DTSTART (UTC) and DTEND (UTC) to
display based on a users timezone preference?

Comment 11

[Mike Potter]

From what I know about ical, any properties starting with X- are not supported.
 Those are application specific properties, so
X-NSCP-DTSTART-TZID:America/New_York would only be useful inside Netscape's server.
However, since we know about it, we may want to patch our ical to read that in.
I don't know how hard that would be.
I think the standard is to set the timezone for the file, as you can see in an
iCal file.

Comment 12

[Mike Potter]

New contact from [e-mail] to [e-mail]
Filter on string OttawaMBA to get rid of these messages. 
Sorry for the spam.

Comment 13

[Alexandre Pauziès]

Hi, 
 
I'm trying to add timezone support to calendar. 
 
In icalfileset_add_first_to_first_component() from oeICalImpl.cpp i added 
this : 
 
icaltimezone *my_timezone = 
icaltimezone_get_builtin_timezone( "Europe/Paris" ); 
icalcomponent_add_component( firstc, 
icaltimezone_get_component( my_timezone ) ); 
 
So when adding an event, if the timezone component is missing on the calendar, 
it is added but this is done by using timezone files from libical which are 
not installed with mozilla. 
 
The timezone component must also be added when getting a remote calendar on 
wich this component is missing. I think this job could be done in SetServer() 
from oeICalImpl.cpp but this job is not easy. 
 
Actually i'm trying to set the timezone manually but it must be taken from 
sunbird settings. 
 
I would appreciate help on this part. 
 
Thanks. 
 
Alexandre 

Comment 14

[Alexandre Pauziès]

Attachment: Allow to choose Date/Time storage format (UTC/Zulu)

Hi,

I made this patch which allow dates storage in GMT.
With this, events could be well exported to remote calendar servers (like
OpenGroupware).
I added an option in Sunbird setting to switch between GMT and Zulu time, and
removed the Timezone selection windows which was not working yet.

Alexandre.

Comment 15

[Mostafa Hosseini]

Comment on attachment 151453 [details] [diff] [review]
Allow to choose Date/Time storage format (UTC/Zulu)

The preference part for adding a "Store in GMT" option looks ok.
The change to support GMT removes support for storing the time in other
timezones though. That support is not available yet but the current code allows
moving towards that direction. m_storeingmt should just result in setting tzid
to "/Mozilla.org/BasicTimezones/GMT"
whenever it is null.

Comment 16

[Alexandre Pauziès]

Attachment: Allow to choose Date/Time storage format (UTC/Zulu)

Ok, here a new one

Comment 17

[Mostafa Hosseini]

Attachment: Revision of previous patch( checked in)

The preference part of the previous patch has been checked in.
The part dealing with the backend code has been revised to touch less code.
Please try and report.

Comment 18

[Ian Bruseker]

I'm not sure if this is a Calendar/Sunbird bug or an Apple bug, but Apple's
Olympic calendar files (available at
http://www.apple.com/ical/library/olympics.html) have a slightly different
DTSTART and DTEND format than others I've seen in this bug.  The main timezone
entry block is similar to others shown above:

BEGIN:VTIMEZONE
TZID:Europe/Athens
LAST-MODIFIED:20040804T213850Z
BEGIN:DAYLIGHT
DTSTART:20040328T010000
TZOFFSETTO:+0300
TZOFFSETFROM:+0000
TZNAME:EEST
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20041031T040000
TZOFFSETTO:+0200
TZOFFSETFROM:+0300
TZNAME:EET
END:STANDARD
END:VTIMEZONE

but the individual events also have the timezone in their DTSTART and DTEND
entries.  Here is a sample entry taken from the Athletics calendar:

BEGIN:VEVENT
LOCATION:Ancient Stadium\, Olympia
DTSTAMP:20040803T172108Z
UID:AC578FA4-E65E-11D8-97B2-000A95985272
SEQUENCE:1
URL;VALUE=URI:http://www.athens2004.com/athens2004/
DTSTART;TZID=Europe/Athens:20040818T083000
SUMMARY:Athletics-Women's Shot Put Qualifying Rounds\nMen's Shot Put Qua
 lifying Rounds
DTEND;TZID=Europe/Athens:20040818T110000
END:VEVENT

Event though my timezone is set to America/Edmonton, this event shows up as
running from 8:30 AM to 11 AM instead of in the middle of the night which is
when it actually takes place.  The result is the same in both Calendar
(2004080916-cal) and Sunbird (0.2a).  Obviously, it shows up at the correct time
in Apple's iCal application.

Comment 19

[Majken Connor [:Kensie]]

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

Comment 20

[Dan Mosedale (:dmosedale, :dmose)]

I believe the switch to the new views has set up all the infrastructure to fix this problem.  The only remaining pieces here are the cases where event creation and modification do the wrong thing.

Comment 21

[Dan Mosedale (:dmosedale, :dmose)]

One remaining problem case is that events created by the new event dialog (in Lightning) at least seem to have the default dates in Zulu.  Im not sure if there are other similar issues.

Comment 22

[Joey Minta]

Attachment: set times in correct timezones

jsDateToDateTime returned a time in UTC.  Therefore, we call getInTimezone on it to convert it to the correct time+timezone.

Comment 23

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 210534 [details] [diff] [review]
set times in correct timezones

r=mvl, although i think we need a different value from the datepicker, one that doesn't require this localtime->utc->localtime chain. But that's a different bug, i guess.

Comment 24

[Joey Minta]

Patch checked in.