Last Comment Bug 367378 - events in Asia/Jerusalem after the daylight saving shift are 1 hour off
: events in Asia/Jerusalem after the daylight saving shift are 1 hour off
Status: VERIFIED FIXED
[verified0.3.1]
: relnote
Product: Calendar
Classification: Client Software
Component: Internal Components (show other bugs)
: Sunbird 0.3.1
: All All
: -- major (vote)
: ---
Assigned To: Matthew (lilmatt) Willis
:
Mentors:
http://www.math.technion.ac.il/~rl/et...
: 378855 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-18 10:42 PST by Zvi Har'El
Modified: 2007-05-26 04:14 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
ICS file showing one event with skewed view time. (781 bytes, text/plain)
2007-01-18 10:48 PST, Zvi Har'El
no flags Details
fixes two timezones (7.51 KB, patch)
2007-02-08 16:51 PST, Matthew (lilmatt) Willis
dmose: first‑review+
dmose: second‑review+
Details | Diff | Review
Shortens the Asia/Jerusalem definition so that the build will not break on 32 bit windows (checked in) (7.10 KB, patch)
2007-02-08 19:51 PST, cmtalbert
no flags Details | Diff | Review
ICS file for the same event. fixed in 0.3.1 release candidate (3.00 KB, text/calendar)
2007-02-09 01:25 PST, Zvi Har'El
no flags Details

Description Zvi Har'El 2007-01-18 10:42:51 PST
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 2007-01-18 10:48:14 PST
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.
Comment 2 Sebastian Schwieger 2007-02-08 13:26:30 PST
The attached ICS file contains a Timezone definition without DST. This is an error in our timezone definitions.
Confirmed.
Comment 3 Matthew (lilmatt) Willis 2007-02-08 16:51:41 PST
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.
Comment 4 Dan Mosedale (:dmose) 2007-02-08 16:54:02 PST
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 2007-02-08 17:17:31 PST
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 2007-02-08 19:51:48 PST
Created attachment 254496 [details] [diff] [review]
Shortens the Asia/Jerusalem definition so that the build will not break on 32 bit windows (checked in)
Comment 7 Zvi Har'El 2007-02-09 01:23:35 PST
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 2007-02-09 01:25:31 PST
Created attachment 254514 [details]
ICS file for the same event. fixed in 0.3.1 release candidate
Comment 9 Zvi Har'El 2007-02-09 09:34:39 PST
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 2007-02-09 09:59:52 PST
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 2007-02-10 01:03:02 PST
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 2007-02-12 05:54:32 PST
(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 2007-02-14 03:51:49 PST
(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 2007-02-14 07:16:46 PST
(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.
Comment 15 Sebastian Schwieger 2007-04-29 14:36:52 PDT
*** Bug 378855 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.