Closed Bug 1237085 Opened 4 years ago Closed 4 years ago

Incorrect timezone handling for US/Pacific timezone

Categories

(Calendar :: General, defect)

Lightning 4.0.4.1
x86_64
Windows 7
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: joshuah, Assigned: darktrojan)

References

Details

(Whiteboard: [timezone])

Attachments

(3 files)

Attached file invite.ics
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151223140742

Steps to reproduce:

0. Create ics file with (deprecated) 'US/Pacific' as the timezone and 11am as the start time.  See attached.
1. Open ics file with Thunderbird/Lightning (File->Open->Calendar File->[select file])



Actual results:

Event is added to calendar at 3:00am in America/Los_Angeles.


Expected results:

Event will be added to calendar at 11:00am same time as America/Los_Angeles.
Before I go into detail, know that I love Lightning, and it's the only calendar app I use.

This particular bug has been a bane of meeting coordination; other people send me invites from Outlook or the company webmail program (Rackspace's webmail app), and the resulting meeting time is nearly always wrong, which is usually followed by accepting the invitation, trying to figure out what time the meeting is supposed to be at, then deleting the event and recreating it.

I've created a custom .ics file for this ticket that reproduces the behavior.

Some possible approaches:
* Add the "US/..." (e.g. "US/Pacific", "US/Eastern", etc.) alias entries to timezones/zones.json.  It would be best to implement ticket 1181304, but a few common ones could be added manually in the short term.
* It appears that Lightning may be using the local time as the reference for VTIMEZONE TZOFFSETFROM and TZOFFSETTO instead of UTC.  Another possible cause is that the VTIMEZONE DTSTART is in the future, and Lightning is getting confused by that.
https://tools.ietf.org/html/rfc5545#section-3.6.5

The zones.json fix worked for me, but it doesn't address the broken VTIMEZONE handling (or, perhaps generation, if the source apps are wrong).
timezones/zones.json
-------------------------------
$ diff -C 10 zones.json zones.json.1
*** zones.json  2016-01-05 15:16:45.710075100 -0800
--- zones.json.1        2016-01-05 15:11:14.388124600 -0800
***************
*** 330,364 ****
      },
      "UCT": {
        "aliasTo": "UTC"
      },
      "US Eastern Standard Time": {
        "aliasTo": "America/Indianapolis"
      },
      "US Mountain Standard Time": {
        "aliasTo": "America/Phoenix"
      },
-     "US/Pacific": {
-       "aliasTo": "America/Los_Angeles"
-     },
-     "US/Pacific-New": {
-       "aliasTo": "America/Los_Angeles"
-     },
-     "US/Mountain": {
-       "aliasTo": "America/Denver"
-     },
-     "US/Central": {
-       "aliasTo": "America/Chicago"
-     },
-     "US/Eastern": {
-       "aliasTo": "America/New_York"
-     },
      "Ulaanbaatar Standard Time": {
        "aliasTo": "Asia/Ulaanbaatar"
      },
      "Universal": {
        "aliasTo": "UTC"
      },
      "Venezuela Standard Time": {
        "aliasTo": "America/Caracas"
      },
      "Vladivostok Standard Time": {
--- 330,349 ----
-------------------------------
The above entries are based on zoneinfo64.txt.  Based on that file, the pre-existing aliases for "US Eastern Standard Time" and "US Mountain Standard Time" appear to be incorrect.

http://mxr.mozilla.org/comm-central/source/mozilla/intl/icu/source/data/misc/zoneinfo64.txt
See Also: → 1181304
Some info from the Troubleshooting page:
--------------------------------------------
Application Basics
Name 	Thunderbird
Version 	38.4.0
User Agent 	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
Profile Folder 	
(Local drive)
Application Build ID 	20151119061742
Enabled Plugins 	about:plugins
Build Configuration 	about:buildconfig
Memory Use 	about:memory


Extensions
Name 	Version 	Enabled 	ID
CompactHeader	2.1.0	true	{58D4392A-842E-11DE-B51A-C7B855D89593}
Lightning	4.0.4.1	true	{e2fda1a4-762b-4020-b5ad-a41df1933103}
Extra Folder Columns	1.1.5	false	extra-cols@jminta_gmail.com
Thunderbird Conversations	2.10.2	false	gconversation@xulforum.org
--------------------------------------------
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Attachment #8704354 - Attachment mime type: text/calendar → text/plain
Have you made sure to configure your local timezone in the Lightning tab of the TB options dialog/tab?
Flags: needinfo?(joshuah)
Flags: needinfo?(joshuah)
I don't know if I explicitly set the timezone; it has been a long time (years) since I installed.  It may have picked it up from the O/S (Windows 7) automatically?
Confirming. We should add the aliases.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Incorrect(?) timezone handling for US/Pacific timezone → Incorrect timezone handling for US/Pacific timezone
Whiteboard: [timezone]
Blocks: ltn47
There's a few things going on here, and just to confuse the issue, we have two sets of code that handle this sort of thing.

You're using libical which, it seems, thinks the event is 8 hours early. I changed the file you attached to use America/Los_Angeles, and everything works as expected. We're not actually maintaining libical (we're making a replacement), so that won't get fixed.

As you say, adding the aliases to the timezones file fixes the problem, and I think we should do that.

> The above entries are based on zoneinfo64.txt.  Based on that file, the pre-existing aliases for "US Eastern Standard Time" and "US Mountain Standard Time" appear to be incorrect.

These two zones are obsolete, despite the name, they're not meant to point to America/New_York or America/Denver.
Attached patch 1237085-1.diffSplinter Review
Adds five aliases to the zones.json file. I've also fixed a mistake in the GData provider's timezoneMap.jsm, since I had it open.
Assignee: nobody → geoff
Status: NEW → ASSIGNED
Attachment #8704849 - Flags: review?(philipp)
Attachment #8704849 - Flags: review?(philipp) → review+
@Geoff Lankow:
* Added aliases: Thanks!
* "US Eastern Standard Time" and "US Mountain Standard Time": Ok.
* libical being replaced: So, it will be fixed by the replacement (someday), right? :)
(In reply to joshuah from comment #9)
> * libical being replaced: So, it will be fixed by the replacement (someday),
> right? :)

The replacement has a different wrong behaviour, but it's better than what libical does. It doesn't use the timezone from the file at all, instead it puts the event into 'local time'. (Bug 1149470)
Comment on attachment 8704849 [details] [diff] [review]
1237085-1.diff

Leaving this patch to be checked in when there's less tree-burning going on.
Attachment #8704849 - Flags: checkin?
Keywords: checkin-needed
Comment on attachment 8704849 [details] [diff] [review]
1237085-1.diff

Probably doesn't hurt to push these aliases to aurora so we can get them into 45.
Attachment #8704849 - Flags: checkin? → approval-calendar-aurora+
https://hg.mozilla.org/comm-central/rev/601987a78df259812d51d19df5ed136016bd6895
Bug 1237085 - Incorrect timezone handling for US/Pacific timezone. r=philipp
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 4.8
As far as I know Lightning with libical did support foreign timezones if there was a valid timezone definition provided with the data. When did this broke and how? 

This seems like a serious regression that basically prevents correct calendar data exchange with third party calendar applications or calendar services because you cannot add every foreign timezone to this fallback lookup table.
Actually the current behavior seems to be correct. The VTIMEZONE component defines that DAYLIGHT time starts on 2016-03-13 and STANDARD time starts on 2016-11-06. Afterwards it repeats on the corresponding Sunday in March/November.

But for dates before 2016-03-13 the UTC offset is simply undefined. From a quick look at RFC 5545 I did not found description how calendar applications should behave in such erroneous case.

Reporter, can you test with a valid VTIMEZONE definition that includes the actual event date?
Maybe you could contact the creator of the application that created the erroneous event.
Keywords: checkin-needed
Whiteboard: [timezone] → [timezone][checkin-needed comm-aurora]
Backported to releases/comm-aurora changeset 88992760923c
Keywords: checkin-needed
Target Milestone: 4.8 → 4.7
Whiteboard: [timezone][checkin-needed comm-aurora] → [timezone]
You need to log in before you can comment on or make changes to this bug.