781 bytes, text/plain
7.51 KB, patch
|Details | Diff | Splinter Review|
Shortens the Asia/Jerusalem definition so that the build will not break on 32 bit windows (checked in)
7.10 KB, patch
|Details | Diff | Splinter Review|
3.00 KB, text/calendar
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20061208 Firefox/220.127.116.11 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.
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.
Version: unspecified → Sunbird 0.3
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
Attachment #251945 - Attachment mime type: text/calendar → text/plain
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 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: 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: 13 years ago
Component: Calendar Views → Internal Components
Flags: blocking-calendar0.3.1? → blocking-calendar0.3.1+
OS: Linux → All
Hardware: PC → All
Resolution: --- → FIXED
Version: Sunbird 0.3 → Sunbird 0.3.1
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.
Status: RESOLVED → VERIFIED
Whiteboard: [fixed0.3.1] → [verified0.3.1]
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
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.
You need to log in before you can comment on or make changes to this bug.