497063 - ICS calendar event using floating time for start and end date-time is incorrectly imported (start and end time interpretated as UTC time)

Status: RESOLVED WORKSFORME

(Calendar :: Import and Export, defect)

Description

[Eric Mounier]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Build Identifier: Ligthning 0.9 build 2008091719

Import of following ics file into Ligthning:
BEGIN:VCALENDAR
PRODID:-//XING//www.xing.com//version 2.0//DE
CALSCALE:Gregorian
BEGIN:VEVENT
DTSTART:20090609T173000
DTEND:20090609T234500
DTSTAMP:20090609T102533
SEQUENCE:0
URL:https://www.xing.com/events/345020
UID:https://www.xing.com/events/345020
SUMMARY:IT-Stammtisch Themenabend "Green-IT" im IBM Forschungslabor in Böbl
 ingen
DESCRIPTION:...\n
LOCATION:Böblingen (Germany)
END:VEVENT
END:VCALENDAR

leads to an event 2 hours later (I'm in the MET time zone with DST on).

The ICS standard RFC2445 specifies floating time to be interpretated as whatever local time is used by the user reading the event:
FORM #1: DATE WITH LOCAL TIME

   The date with local time form is simply a date-time value that does
   not contain the UTC designator nor does it reference a time zone. For
   example, the following represents Janurary 18, 1998, at 11 PM:

     DTSTART:19980118T230000

   Date-time values of this type are said to be "floating" and are not
   bound to any time zone in particular. They are used to represent the
   same hour, minute, and second value regardless of which time zone is
   currently being observed. For example, an event can be defined that
   indicates that an individual will be busy from 11:00 AM to 1:00 PM
   every day, no matter which time zone the person is in. In these
   cases, a local time can be specified. The recipient of an iCalendar
   object with a property value consisting of a local time, without any
   relative time zone information, SHOULD interpret the value as being
   fixed to whatever time zone the ATTENDEE is in at any given moment.
   This means that two ATTENDEEs, in different time zones, receiving the
   same event definition as a floating time, may be participating in the
   event at different actual times. Floating time SHOULD only be used
   where that is the reasonable behavior.

I've already missed some events due to this bug ;-)...

Reproducible: Always

Steps to Reproduce:
1. export or generate an ICS event
2. set the STARTTIME field as floating time
3. import it in Lightning (you have previously set your timezone different from UTC) 
4. 
Actual Results:  
the imported event is delayed by the time difference UTC and your local timezone

Expected Results:  
the imported event shall have a correct start and end date, i.e. the ones specified in the ICS file as local time

Comment 1

[Stefan Sitter [:ssitter]]

Works fine for me using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090608 Calendar/1.0pre. Timezone of OS and Sunbird is Europe/Berlin. Tested both storage and ics calendar provider.

Comment 2

[Mastacheata]

Sunbird is pretty fault tolerant here.
The iCalendar Specification (RFC 2445) says that DtStart has to be specified in Local Time and DtEnd in UTC (Which Sunbird on the other hand doesn't evaluate correctly)
http://tools.ietf.org/html/rfc2445#section-4.8.2

Comment 3

[Stefan Sitter [:ssitter]]

I assume you misread the paragraph or maybe mixed up COMPLETED with DTEND? RFC2445 doesn't state that DTSTART has to be specified in Local Time and DTEND in UTC. For DTSTART no limitation is specified and for DTEND it is only required to match DTSTART.

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-10#section-3.8.2.4

> 3.8.2.4.  Date/Time Start
> Property Name:  DTSTART
> ...
> Description:  Within the "VEVENT" calendar component, this property
>    defines the start date and time for the event.

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-10#section-3.8.2.2

> 3.8.2.2.  Date/Time End
> Property Name:  DTEND
> ...
> Description:  Within the "VEVENT" calendar component, this property
>    defines the date and time by which the event ends.  The value type
>    of this property MUST be the same as the "DTSTART" property, and
>    its value MUST be later in time than the value of the "DTSTART"
>    property.  Furthermore, this property MUST be specified as a date
>    with local time if and only if the "DTSTART" property is also
>    specified as a date with local time.

There are some restrictions if DTSTART/DTEND are contained within a VTIMEZONE or VFREEBUSY component but this report is about VEVENT, see comment #0.

Comment 4

[Mastacheata]

I'm sorry I misread / misinterpreted that restrictions being valid for all Components.

Comment 5

[xjqcf]

I have encountered this problem when using a csv file import. I had created a csv file by exporting from Microsoft outlook. The times were expressed in terms of my local time (US Eastern Standard Time, UTC-5.0). The import times are interpreted as UTC. Because of the possibility that any file might have local times expressed in based on arbitrary time zones I think the import filter needs to prompt the user as to what times are used in the file being imported. It should be the local installation's responsibility to control the display/usage of times after import. 

Of course, there is the possibility of some times which are truly floating (e. g. at 12:00 Noon local time you must swing a rubber chicken around your head 3 times) but I suspect that assuming times are fixed will cover most cases.

Comment 6

[Philipp Kewisch [:Fallen][📱📆]]

xjqcf, csv importing is not related to this bug, please search bugzilla, I believe we have other bugs that handle your issue.

Related to this bug, is there anything left to do? It seems all issues described here are WORKSFORME?

Comment 7

[Wayne Mery (:wsmwk)]

no response, so WFM per comment 6.