User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20061208 Firefox/18.104.22.168
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.
Steps to Reproduce:
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.
The attached ICS file contains a Timezone definition without DST. This is an error in our timezone definitions.
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:
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 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.
Patch checked in on:
Release note added to:
Notes added to wiki at:
Created attachment 254496 [details] [diff] [review]
Shortens the Asia/Jerusalem definition so that the build will not break on 32 bit windows (checked in)
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.
Created attachment 254514 [details]
ICS file for the same event. fixed in 0.3.1 release candidate
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.
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.
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.
(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.
(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.
(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.
*** Bug 378855 has been marked as a duplicate of this bug. ***