Open Bug 440682 Opened 16 years ago Updated 2 years ago

Date-times that don't fall into the range of their timezone definition are treated as UTC

Categories

(Calendar :: Provider: ICS/WebDAV, defect)

Product:
Calendar
Component:
Provider: ICS/WebDAV
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

People

(Reporter: mozilla, Unassigned)

Details

Attachments

(4 files, 1 obsolete file)

VCALENDAR which is displayed correctly
858 bytes, text/plain
Details
VCALENDAR which attempts to redefine the Australia/Perth timezone
851 bytes, text/plain
Details
Corrected file showing the original problem
866 bytes, text/plain
Details
VCalendar file with deliberate error
869 bytes, text/plain
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071030 Fedora/2.0.0.8-2.fc8 Firefox/2.0.0.8
Build Identifier: Lightning 0.9pre (build 2008061918)

If a DTSTART or DTEND property refers to a TZID (timezone) defined within the VCALENDAR file itself, then that timezone information is ignored, and the date-time value is treated as if it had been defined in UTC instead.

I have verified this in the following product combinations:

* Lightning 0.8; Thunderbird 2.0.0.12; linux
* Lightning 0.9pre (build 2008061918); Thunderbird 2.0.0.12; linux
* Lightning 0.7 Thunderbird 1.5.0.8; Windows XP

For example, if a VCALENDAR file looks (in part) like this:

BEGIN:VCALENDAR
...
BEGIN:VTIMEZONE
TZID:MyTimezoneDefinition
...
END:VTIMEZONE
BEGIN:VEVENT
...
DTSTART;TZID=MyTimezoneDefinition:20080618T100000
DTEND;TZID=MyTimezoneDefinition:20080618T120000

Then DTSTART and DTEND are treated as being in UTC instead of being in the MyTimezoneDefinition timezone.

If I change the TZID in DTSTART and DTEND to one of the standard ones recognised by Lightning, eg "Australia/Sydney", then the time is correctly treated as being in that timezone.

In all cases the definition within the VTIMEZONE definition is ignored.

Reproducible: Always

Steps to Reproduce:
1. create a VCALENDAR with an embedded VTIMEZONE definition;
2. set the DTSTART and DTEND to refer to that timezone by TZID, and set the date and times to be in that timezone;
3. attach that ical file to an email and send it to yourself
4. view the email. The start and end time will have been adjusted to your local timezone as if they had been specifified in UTC time.

Another way that I've found to reproduce this is to get someone I know who uses Entourage to send me an invitation, as Entourage tends to (maybe always does) embed the timezone information using non-standard names.
Actual Results:  
The start and end times have been adjusted to the local timezone, as if they had been specified in UTC.

My local timezone is GMT+10000, so I see the start and end times as being 10 hours later than they were specified in the VCALENDAR.

Expected Results:  
The start and end time should be displayed correctly in the local timezone. And for that to happen, they needed first to have been correctly interpreted as being in the specified timezone.

I can provide VCALENDAR files that exhibit the different behaviour. I presume I can attach files in subsequent comments?

I've set this severity to "major" as some proportion of received appointments etc may be displayed with significantly wrong times, potentially causing users to work with incorrect appointment times without knowing there is anything wrong.
Dates and times are always displayed in the timezone that you have configured in the Lightning preferences. Please check that the timezone is correct configured.

What type of calendar do you use to store the events? A local storage calendar, an ics file (local or remote), a CalDAV server, etc?

Please attach a testcase ics file that can be used to reproduce the issue in a recent Sunbird/Lightning nightly build.
Attached file VCALENDAR which exhibits the problem (obsolete) — 
This is a complete VCALENDAR in an ICS file, with an internally defined timezone (see VTIMEZONE). It exhibits the problem.
In this VCALENDAR, I have changed the TZID in the DTSTART and DTEND properties to one of the globally recognised ones: "Australia/Sydney". Lightning displays this correctly.
I tried this to see which piece of logic is taking precedence. I changed the TZID of the internally defined VTIMEZONE to coincide with one of the globally defined ones (Australia/Perth). However, I left the timezone definition to be that of Sydney (2 hours different).

The result is that the DTSTART and DTEND are displayed according the the Lightning definition of Perth time, *not* the definition inside the VCALENDAR.

This may be regarded as "correct" behaviour and I am not suggesting otherwise. I am just demonstrating that this is another situation in which the internally defined VTIMEZONE information is ignored.
Hi Stefan,

> Dates and times are always displayed in the timezone that you have configured
in the Lightning preferences.
I'm not disagreeing with that. The problem is that the DTSTART and DTEND values are not being adjusted to the specified timezone of the originator *before* the local timezone is applied.

> Please check that the timezone is correct configured.
My Lightning timezone is set to Australia/Sydney (which is GMT+1000).

> What type of calendar do you use to store the events?
This is an ICS remote calendar. The server is an Apache server with the WebDav module loaded.

However to be clear: the incorrect times are also being displayed in the email in Thunderbird, as well as in the Lightning calendar.

> Please attach a testcase ics file that can be used to reproduce the issue
:o) Yup - I was in the process of doing that when you posted :o)
Seems you guys are lightning in nature as well as in product name - I'm impressed.

Cheers!
Nik
Comment on attachment 325957 [details]
VCALENDAR which exhibits the problem

...
>DTSTART;TZID=MyTimezoneDefinition:20080618T100000
>DTEND;TZID=MyTimezonDefinition:20080618T120000
BTW: There's actually a typo in this file: DTEND's TZID is unknown, thus shown as "Local Time".
> BTW: There's actually a typo in this file: DTEND's TZID is unknown, thus shown
> as "Local Time".

Good point. My apologies. I should have been more careful with that.

However, the DTSTART does exhibit the isue.

I will upload a corrected file
A typo in the original file caused only DTSTART to show the problem, and DTEND to fall-back to local time
Attachment #325957 - Attachment is obsolete: true
(In reply to comment #5)
> > Please check that the timezone is correct configured.
> My Lightning timezone is set to Australia/Sydney (which is GMT+1000).
I think that's wrong: http://timeanddate.com/worldclock/results.html?query=Perth
(In reply to comment #9)
> (In reply to comment #5)
> > > Please check that the timezone is correct configured.
> > My Lightning timezone is set to Australia/Sydney (which is GMT+1000).
> I think that's wrong:
> http://timeanddate.com/worldclock/results.html?query=Perth
I'm sorry, don't know why I thought about perth...


Ok, this has had no activity for a while now.

Since I've already checked out the nightly-build code, I am happy to update and go looking for the problem.

It would save me some time if somebody could give me some pointers as to where I should be looking. I infer that some of the timezone logic is in a library?
Can anyone give me a short list of source files (lightning and/or library) where I should start my investigation?

Cheers!
Nik
You should go into this code (VTIMEZONE lookup in parent VCALENDAR):
<http://mxr.mozilla.org/mozilla1.8/source/calendar/base/src/calICSService.cpp#418>

However what's more interesting is to look if the VTIMEZONE has correctly been parsed. Subscribing your ics file, it at least has the correct TZID.

Ok, should I change this bug's status to "assigned"? And if so, how?

> You should go into this code
Awesome! Thank you - and even more for showing me where the mxr URI resides! :o)

> However what's more interesting is to look if the VTIMEZONE has
> correctly been parsed.

Yes, I was wondering if the problem was with the TZID lookup or the VTIMEZONE parsing.

> Subscribing your ics file, it at least has the correct TZID.
I'm not sure I understand this sentence. Are you saying you've tested my ics file by "subscribing" it? Ot are you suggesting I do this. And my apologies for appearing inept here, but what exactly do you mean by "subscribing" - and to what should I be doing this subscribing?

Thanks again for all your help!

Cheers!
Nik
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(In reply to comment #14)
> > Subscribing your ics file, it at least has the correct TZID.
> I'm not sure I understand this sentence. Are you saying you've tested my ics
> file by "subscribing" it? Ot are you suggesting I do this. And my apologies for
> appearing inept here, but what exactly do you mean by "subscribing" - and to
> what should I be doing this subscribing?
> 
I've downloaded it and subscribed to the ics file.

My apologie for being so thick here...

> I've downloaded it and subscribed to the ics file.
Using which software?
Does this success indicate only that the original file format is correct, or does it mean that some part of the lightning code recognises it correctly?

Cheers!
Nik
VCalendar file with a deliberate error.

The TZID reference in the DTSTART and DTEND does not refer to a valid TZID in the VCalendar file.

The result (on my version of lightning) is that the times are shown correctly. This implies that if lightning cannot find a VTIMEZONE for the specified TZID, then it assumes that the DTSTART or DTEND in question originated in the local timezone.

This is *different* to the behaviour where the TZID correctly refers to a VTIMEZONE within the VCALENDAR file, but that VTIMEZONE ID is *not* one of the globally recognised by lightning. In this situation, lightning behaves as if the DTSTART or DTEND times were originally in GMT time - usually causing incorrect results once the local timezone has been applied.

Cheers!
Nik
Did we lose foreign timezone support along the way, can someone confirm this?
(In reply to comment #17)
> The TZID reference in the DTSTART and DTEND does not refer to a valid TZID in
> the VCalendar file.
> The result (on my version of lightning) is that the times are shown correctly.
> This implies that if lightning cannot find a VTIMEZONE for the specified TZID,
> then it assumes that the DTSTART or DTEND in question originated in the local
> timezone.

That's Bug 419007.
Attachment #328817 - Attachment mime type: text/calendar → text/plain
> That's Bug 419007.
Ok, thanks.

I wasn't actually trying to point out any further problem. I was actually pointing out that this implies that the current bug (440682) is probably not caused by not being able to find the TZID correctly (since the behaviour is different). It implies rather that the VTIMEZONE entry is being found, but handled incorrectly.

Apologies for any confusion caused.

Cheers!
Nik
ASSIGNED to nobody -> Back to NEW
Status: ASSIGNED → NEW
I think I found where the problem is. I tried in 0.8 and the example appointment showed the same behaviour but we did have foreign timezones in 0.8. Gathering something should be wrong with the ics itself, though I coulnd't find anything at first. 

According to your timezone-definition stdardtime starts the last sunday of march beginning at april 6 at 20:00. So the first time standardtime becomes active is march 30th, 2009. This means at the moment there's no valid timezone defined -> falling back to UTC. 

Shouldn't we fire a warning in cases like these or shouldn't we revert to local time like we do with undefined timezone's? I think however this would require libibal to be altered... 

Reporter, which program created your original testcase? 
Hi Bas, thanks for your help!

I had finally got a lightning build environment together (half a gigabyte download!!), and was just instrumenting the code to find out how things were being handled.

> So the first time standardtime becomes active is march 30th, 2009.
I am by no means an expert on the iCal format.
I had missed that that there is effectively a conflict between the RRULE and the DTSTART in the VTIMEZONE. If that VTIMEZONE should indeed be interpreted as you say it should (and it certainly sounds reasonable), then the iCal entry is effectively broken.

> Reporter, which program created your original testcase?
I  believe it was Entourage on Mac. The PRODID in the test file was copied directly from the original problem appointment.

I will check, but I believe that Outlook appeared to infer the timezone correctly from this one.

I think your suggested behaviour is probably the most predictable, but I just wonder whether Outlook perhaps assumes that in the absence of actual information, *last* year was the same as *this* year, and just ignores the DTSTART field in the VTIMEZONE?

One last point, just to avoid any confusion for others when reading this:
> stdardtime starts the last sunday of march beginning at april 6 at 20:00
I think the definition actually says it starts at 02:00, which is a more normal time to start a timezone.

This VTIMEZONE entry from Entourage is actually quite interesting. This year, Sydney extended daylight savings, so instead of ending on March 30th 2008, it ended this year on April 6th 2008.

http://www.news.com.au/technology/story/0,25642,23458405-5014239,00.html?CMP=KNC-google

So perhaps someone has updated the timezone defintion that Entourage is using by changing the timezone start date-time without realising that they needed to change the RRULE as well? I don't know if this is a problem at just one site, or a problem in some global timezone definition that all Entourage users are using.

I'll get our guys to find out.

Thanks again for all your help!

Cheers!
Nik
Just to confirm:

I modified the iCal file so that the RRULE agreed with the DTSTART field, and lightning 0.9 now displays the correct time.

I will test this with 0.8 and 0.7 next week.

Cheers!
Nik
Severity: major → normal
Summary: TimeZone definitions within a VCALENDAR file are ignored → Date-times that don't fall into the range of their timezone definition are treated as UTC
I just got a similar ics file from apple support where the DTSTART's were wrong.  Not sure what's the best thing to do here.
For the record:

DTSTART:20150311T020000
RRULE:YEARLY;BYMONTH=03;BYDAY=2SU
(which is after the start on the 8th)

DTSTART:20151103T020000
RRULE:YEARLY;BYMONTH=11;BYDAY=1SU
(which is before the end on the 8th)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: