523621 - Update internal timezone database to version 2009p

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Simon Vaillancourt]

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 [:ssitter]]

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 [:ssitter]]

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]]

(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]]

(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]

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]

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]]

Attachment: diff -U8 timezones_before_update.dump timezones.dump

Comment 8

[Daniel Boelzle [:dbo]]

Attachment: 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]]

(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]

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 [:ssitter]]

Comment on attachment 409348 [details] [diff] [review]
patch - v1

r=ssitter

Comment 12

[Daniel Boelzle [:dbo]]

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] [:📆][:🧩]]

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".