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

VERIFIED FIXED

Status

Calendar
Internal Components
--
major
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: Zvi Har'El, Assigned: Matthew (lilmatt) Willis)

Tracking

({relnote})

Sunbird 0.3.1
relnote

Details

(Whiteboard: [verified0.3.1], URL)

Attachments

(4 attachments)

(Reporter)

Description

10 years ago
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.
(Reporter)

Comment 1

10 years ago
Created attachment 251945 [details]
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.
Keywords: qawanted
Version: unspecified → Sunbird 0.3

Comment 2

10 years ago
The attached ICS file contains a Timezone definition without DST. This is an error in our timezone definitions.
Confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-calendar0.3.1?
(Assignee)

Updated

10 years ago
Attachment #251945 - Attachment mime type: text/calendar → text/plain
Keywords: qawanted
(Assignee)

Comment 3

10 years ago
Created attachment 254472 [details] [diff] [review]
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.
Assignee: nobody → lilmatt
Status: NEW → ASSIGNED
Attachment #254472 - Flags: second-review?(dmose)
Attachment #254472 - Flags: first-review?(dmose)

Comment 4

10 years ago
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.
Attachment #254472 - Flags: second-review?(dmose)
Attachment #254472 - Flags: second-review+
Attachment #254472 - Flags: first-review?(dmose)
Attachment #254472 - Flags: first-review+
(Assignee)

Comment 5

10 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Component: Calendar Views → Internal Components
Flags: blocking-calendar0.3.1? → blocking-calendar0.3.1+
OS: Linux → All
Hardware: PC → All
Resolution: --- → FIXED
Whiteboard: [fixed0.3.1]
Version: Sunbird 0.3 → Sunbird 0.3.1

Comment 6

10 years ago
Created attachment 254496 [details] [diff] [review]
Shortens the Asia/Jerusalem definition so that the build will not break on 32 bit windows (checked in)
Attachment #254496 - Flags: first-review?(lilmatt)
(Reporter)

Comment 7

10 years ago
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.
(Reporter)

Comment 8

10 years ago
Created attachment 254514 [details]
ICS file for the same event. fixed in 0.3.1 release candidate
(Assignee)

Updated

10 years ago
Attachment #254496 - Attachment description: Shortens the Asia/Jerusalem definition so that the build will not break on 32 bit windows → Shortens the Asia/Jerusalem definition so that the build will not break on 32 bit windows (checked in)
Attachment #254496 - Flags: first-review?(lilmatt)
(Assignee)

Updated

10 years ago
Status: RESOLVED → VERIFIED
Whiteboard: [fixed0.3.1] → [verified0.3.1]
(Assignee)

Updated

10 years ago
Summary: creating an event which occures after the daylight saving shift, make view 1 hour off → events in Asia/Jerusalem after the daylight saving shift are 1 hour off
(Reporter)

Comment 9

10 years ago
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.
(Assignee)

Comment 10

10 years ago
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

10 years ago
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

10 years ago
(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

10 years ago
(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

10 years ago
(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.

Updated

10 years ago
Duplicate of this bug: 378855

Updated

10 years ago
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.