367378 - events in Asia/Jerusalem after the daylight saving shift are 1 hour off

Status: VERIFIED FIXED

(Calendar :: Internal Components, defect)

Description

[Zvi Har'El]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061006 Sunbird/0.3

I created today, when daylight saving IS NOT in effect, an event in May Day, when daylight saving WILL BE in effect. I set the time of the event from 20:00 to 21:00 In the week or month etc. views, it shows 19:00 to 20:00. In the event editing window, it shows 20:00 to 21:00. In the ICS file, It shows 19:00-21:00+0200, which is really 20:00-21:00+0300, which is correct (I am using Asia/Jerusalem timezone, and It is set inside Sunbird and shown in the ICS file). You can see the ICS file in the URL I specified.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Zvi Har'El]

Attachment: ICS file showing one event with skewed view time.

Install this in your Sunbird Calendar, and compare the Day View of 1 May 2007 with the event edit view of the event shown at 19:00-20:00. The event edit will show start time of 20:00 and end time of 21:00, as it should be.

Comment 2

[Sebastian Schwieger]

The attached ICS file contains a Timezone definition without DST. This is an error in our timezone definitions.
Confirmed.

Comment 3

[Matthew (lilmatt) Willis]

Attachment: fixes two timezones

After comparing the list of timezones without a BEGIN:DAYLIGHT section to Olson, we found the following timezones needed an update:
/mozilla.org/20070129_1/America/Tegucigalpa
/mozilla.org/20070129_1/Asia/Jerusalem

Due to complexity, /Asia/Jerusalem is nearly impossible to represent accurately in an Outlook-compatible format.  As a result, we've taken the timezone output by vzic --pure for /Asia/Jerusalem only.  This _will_ break Outlook 2000 and 2003 compatibility for events in this timezone _only_.  This is the trade-off we're making.

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 254472 [details] [diff] [review]
fixes two timezones

r1/r2=dmose; we should relnote Jerusalem's issue, and document on the wiki somewhere the procedure that we went through here.

Comment 5

[Matthew (lilmatt) Willis]

Patch checked in on:
  SUNBIRD_0_3_BRANCH
  LIGHTNING_0_3_BRANCH
  MOZILLA_1_8_BRANCH
  trunk

Release note added to:
http://www.mozilla.org/projects/calendar/releases/common0.3.1.html

Notes added to wiki at:
http://wiki.mozilla.org/Calendar:Updating_Timezones

-> FIXED

Comment 6

[cmtalbert]

Attachment: Shortens the Asia/Jerusalem definition so that the build will not break on 32 bit windows (checked in)

Comment 7

[Zvi Har'El]

Downloaded release candidate 0.3.1. The problem is fixed. The generated ics files now includes the DST definition, although only from the year 2000 onword. You can view the new ics file in http://www.math.technion.ac.il/~rl/etc/test-0.3.1.ics, or in the attachment.

Comment 8

[Zvi Har'El]

Attachment: ICS file for the same event. fixed in 0.3.1 release candidate

Comment 9

[Zvi Har'El]

About shorting the VTIMEZONE block, I think that the cutoff year 0f 2000 is arbitrary. Isn't it better to put in the ICS file only that part which is relevant to the VEVENTs? For example, the only event I have occurs in 2007, 2007 is enough.

Comment 10

[Matthew (lilmatt) Willis]

Perhaps, however with 0.3.1 so close, any added code to do just would not have enough test coverage to ensure it didn't break things horribly elsewhere.

Comment 11

[Stefan Sitter [:ssitter]]

For the notes: 
en-US win32 build of 0.3.1rc1 has BuildID 2007020822 and includes the fix. All other locales have BuildID 2007020803 - that means the fix is not included.

Comment 12

[cmtalbert]

(In reply to comment #9)
> About shorting the VTIMEZONE block, I think that the cutoff year 0f 2000 is
> arbitrary. Isn't it better to put in the ICS file only that part which is
> relevant to the VEVENTs? For example, the only event I have occurs in 2007,
> 2007 is enough.
> 

Yes, the year 2000 cutoff is arbitrary.  With the tight schedule around 0.3.1 this was as best we could do in order to accurately represent the Asia/Jerusalem timezone.  We will look into a more complete solution for 0.5, when we make several other upgrades to the way we handle timezones.

I'm glad that the bug is fixed, thanks for bringing the bug and the fix to our attention. 

Comment 13

[Sebastian Schwieger]

(In reply to comment #12)
> We will look into a more complete solution for 0.5,
> when we make several other upgrades to the way we handle timezones.
> 
Is there already a bug for that? Otherwise this one should be reopened.

Comment 14

[cmtalbert]

(In reply to comment #13)
> Is there already a bug for that? Otherwise this one should be reopened.
> 

Should have mentioned that, sorry. It's bug 363191.