Last Comment Bug 523621 - Update internal timezone database to version 2009p
: Update internal timezone database to version 2009p
Status: RESOLVED FIXED
:
Product: Calendar
Classification: Client Software
Component: General (show other bugs)
: unspecified
: All All
: -- normal (vote)
: 1.0b1
Assigned To: Daniel Boelzle [:dbo]
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-21 08:43 PDT by Simon Vaillancourt
Modified: 2011-11-07 03:57 PST (History)
0 users
ssitter: blocking‑calendar1.0+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
diff -U8 timezones_before_update.dump timezones.dump (5.21 KB, patch)
2009-10-30 09:39 PDT, Daniel Boelzle [:dbo]
no flags Details | Diff | Splinter Review
patch - v1 (25.18 KB, patch)
2009-10-30 09:40 PDT, Daniel Boelzle [:dbo]
ssitter: review+
Details | Diff | Splinter Review

Description Simon Vaillancourt 2009-10-21 08:43:39 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.14) Gecko/2009082707 Firefox/2.0.0.18 X-ORACLE-DEBUG=STATS (.NET CLR 3.5.30729)
Build Identifier: 

On 2009-10-26, a new Olson db package will be released (tzdata2009p.tar.gz) That contains an important timezone rule change for Argentina (most of Argentina not using DST in 2009-2010). So a new package should be built and pushed to Mozilla addOn site with these changes.

Reproducible: Always
Comment 1 Stefan Sitter 2009-10-21 09:51:25 PDT
The timezone extension is currently tightly integrated into Sunbird. Update is not yet possible, see Bug 406579. Lightning includes the database file itself without using the timezone extension. Timezone update is only possible by installing a new Sunbird/Lightning release.

Once released the Olson timezone database can be downloaded from <ftp://elsie.nci.nih.gov/pub/>.
Comment 2 Stefan Sitter 2009-10-21 09:55:44 PDT
Before the next timezone database release, someone should check the issues mentioned in Bug 473915, Bug 459184, Bug 504299, etc.
Comment 3 Daniel Boelzle [:dbo] 2009-10-22 09:38:26 PDT
(In reply to comment #1)
> The timezone extension is currently tightly integrated into Sunbird. Update is
> not yet possible, see Bug 406579. Lightning includes the database file itself
> without using the timezone extension. Timezone update is only possible by
> installing a new Sunbird/Lightning release.
The last sentence is not correct. Indeed Sunbird/Lightning does not probe for an update of the calendar-timezones.xpi (since it's not pre-installed). But you could manually install one from AMO (when it's finally available for the first time, anyway) and that one would receive automatic updates later on. See the probing logic, an installed calendar-timezones.xpi supersedes the built-in data:
<http://mxr.mozilla.org/comm-central/source/calendar/base/src/calTimezoneService.js#135>

(In reply to comment #2)
> Before the next timezone database release, someone should check the issues
> mentioned in Bug 473915, Bug 459184, Bug 504299, etc.
Why do you think so? I think vzic has problems with the mentioned timezones (australia, Jerusalem), but IMO it's worth to cover updates anyway for the rest of the world.
Comment 4 Daniel Boelzle [:dbo] 2009-10-22 09:40:21 PDT
(In reply to comment #2)
> Before the next timezone database release, someone should check the issues
> mentioned in Bug 473915, Bug 459184, Bug 504299, etc.
Reading again, I might got you wrong. Do you think about that 2009p might fix those issues?
Comment 5 Simon Vaillancourt 2009-10-26 08:51:45 PDT
From the Timezone mailing list:

	ftp://elsie.nci.nih.gov/pub/tzdata2009p.tar.gz

...is now available; this reflects the Argentina (including San Luis) changes circulated on the time zone mailing list last week (with the correction from Mariano Absatz).
Comment 6 Simon Vaillancourt 2009-10-27 17:07:00 PDT
note that because there is a 2038 year in the southamerica file, vzic 1.3 aborts and does not convert that file, workaround is to edit southamerica file to set the year to 2037.  

I am not sure vzic is still maintained by the original author, maybe it would be a good thing to add the source to calendar/timezones so that minor fixes like this one can be done.
Comment 7 Daniel Boelzle [:dbo] 2009-10-30 09:39:39 PDT
Created attachment 409347 [details] [diff] [review]
diff -U8 timezones_before_update.dump timezones.dump
Comment 8 Daniel Boelzle [:dbo] 2009-10-30 09:40:46 PDT
Created attachment 409348 [details] [diff] [review]
patch - v1

Changes needed for /Users/dbo/moz/src/calendar/timezones/../../calendar/locales/en-US/chrome/calendar/timezones.properties:
---
---


timezone has been updated: America/Argentina/Buenos_Aires
timezone has been updated: America/Argentina/Cordoba
timezone has been updated: America/Argentina/San_Luis
timezone has been updated: America/Argentina/Tucuman
timezone has been updated: Asia/Gaza
timezone has been updated: Asia/Karachi
timezone has been updated: Australia/Currie
timezone has been updated: Australia/Hobart
timezone: Pacific/Wallis    [t]ake over as is or use [a]lias? t


Changes needed for /Users/dbo/moz/src/calendar/timezones/../../calendar/locales/en-US/chrome/calendar/timezones.properties:
---
---



DONE.
Comment 9 Daniel Boelzle [:dbo] 2009-10-30 09:42:55 PDT
(In reply to comment #6)
> note that because there is a 2038 year in the southamerica file, vzic 1.3
> aborts and does not convert that file, workaround is to edit southamerica file
> to set the year to 2037.  

Hmm, I don't see this running vzic 1.3, at least it doesn't show it. Output is

[~/work/vzic/vzic-1.3]$ ./vzic
WARNING: Antarctica/Palmer: Modifying RRULE to be compatible with Outlook (day >= 9, month = 10)
WARNING: Antarctica/Palmer: Modifying RRULE to be compatible with Outlook (day >= 9, month = 3)
Skipping DAYLIGHT change
WARNING: Couldn't find a LETTER_S to use in FORMAT: CHO%sT in Zone: Asia/Choibalsan Leaving TZNAME empty
WARNING: Asia/Karachi: Outputting BYDAY=1SU instead of BYMONTHDAY=1-7 for Outlook compatability
WARNING: Asia/Karachi: Outputting BYDAY=3SU instead of BYMONTHDAY=15-21 for Outlook compatability
WARNING: Asia/Damascus: Outputting BYDAY=1SU instead of BYMONTHDAY=1-7 for Outlook compatability
WARNING: America/Godthab: Modifying RRULE to be compatible with Outlook (day >= 24, month = 3)
WARNING: America/Godthab: Modifying RRULE to be compatible with Outlook (day >= 24, month = 10)
WARNING: Couldn't find a LETTER_S to use in FORMAT: M%sT in Zone: America/Inuvik Leaving TZNAME empty
WARNING: Couldn't find a LETTER_S to use in FORMAT: P%sT in Zone: America/Whitehorse Leaving TZNAME empty
WARNING: Couldn't find a LETTER_S to use in FORMAT: P%sT in Zone: America/Dawson Leaving TZNAME empty
WARNING: Couldn't find a LETTER_S to use in FORMAT: AR%sT in Zone: America/Argentina/San_Luis Leaving TZNAME empty
WARNING: America/Santiago: Modifying RRULE to be compatible with Outlook (day >= 9, month = 10)
WARNING: America/Santiago: Modifying RRULE to be compatible with Outlook (day >= 9, month = 3)


> 
> I am not sure vzic is still maintained by the original author, maybe it would
> be a good thing to add the source to calendar/timezones so that minor fixes
> like this one can be done.

good idea
Comment 10 Simon Vaillancourt 2009-10-30 12:49:17 PDT
Here is my output, see last 2 lines, if you look at your southamerica file line 936 do you see a year 2038? If yes I think it should fail in vzic-parse.c line 540:
./vzic
WARNING: Antarctica/Palmer: Modifying RRULE to be compatible with Outlook (day >= 9, month = 10)
WARNING: Antarctica/Palmer: Modifying RRULE to be compatible with Outlook (day >= 9, month = 3)
Skipping DAYLIGHT change
WARNING: Couldn't find a LETTER_S to use in FORMAT: CHO%sT in Zone: Asia/Choibalsan Leaving TZNAME empty
WARNING: Asia/Karachi: Outputting BYDAY=1SU instead of BYMONTHDAY=1-7 for Outlook compatability
WARNING: Asia/Karachi: Outputting BYDAY=3SU instead of BYMONTHDAY=15-21 for Outlook compatability
WARNING: Asia/Damascus: Outputting BYDAY=1SU instead of BYMONTHDAY=1-7 for Outlook compatability
WARNING: America/Godthab: Modifying RRULE to be compatible with Outlook (day >= 24, month = 3)
WARNING: America/Godthab: Modifying RRULE to be compatible with Outlook (day >= 24, month = 10)
WARNING: Couldn't find a LETTER_S to use in FORMAT: M%sT in Zone: America/Inuvik Leaving TZNAME empty
WARNING: Couldn't find a LETTER_S to use in FORMAT: P%sT in Zone: America/Whitehorse Leaving TZNAME empty
WARNING: Couldn't find a LETTER_S to use in FORMAT: P%sT in Zone: America/Dawson Leaving TZNAME empty
..//southamerica:936: Strange year: 2038
Rule    Brazil  2038    max     -       Feb     Sun>=15 0:00    0       -
Comment 11 Stefan Sitter 2009-11-04 10:04:32 PST
Comment on attachment 409348 [details] [diff] [review]
patch - v1

r=ssitter
Comment 12 Daniel Boelzle [:dbo] 2009-11-05 02:19:34 PST
Pushed to comm-1.9.1
<http://hg.mozilla.org/releases/comm-1.9.1/rev/ed1a043afee4>
and comm-central
<http://hg.mozilla.org/comm-central/rev/547c05401190>.

-> FIXED

(In reply to comment #10)
> Here is my output, see last 2 lines, if you look at your southamerica file line
> 936 do you see a year 2038? If yes I think it should fail in vzic-parse.c line
> 540:
...
> ..//southamerica:936: Strange year: 2038
> Rule    Brazil  2038    max     -       Feb     Sun>=15 0:00    0       -
^^^^
Strange, I don't have that line in my output. Maybe we have different vzic 1.3 sources?? Or maybe the code is not x-platform-clean? I am using a Mac's (Apple's gcc4.2.1).
Comment 13 Philipp Kewisch [:Fallen] 2011-11-07 03:57:29 PST
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".

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