Update internal timezone database to version 2009p

RESOLVED FIXED in 1.0b1

Status

Calendar
General
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: Simon Vaillancourt, Assigned: dbo)

Tracking

unspecified
1.0b1
Bug Flags:
blocking-calendar1.0 +

Details

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
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

8 years ago
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/>.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-calendar1.0+
Summary: Generate a new calendar-timezones.xpi for Argentina timezone rule change → Update internal timezone database to version 2009p

Comment 2

8 years ago
Before the next timezone database release, someone should check the issues mentioned in Bug 473915, Bug 459184, Bug 504299, etc.
(Assignee)

Comment 3

8 years ago
(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.
(Assignee)

Comment 4

8 years ago
(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?
(Reporter)

Comment 5

8 years ago
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).
(Reporter)

Comment 6

8 years ago
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.
(Assignee)

Comment 7

8 years ago
Created attachment 409347 [details] [diff] [review]
diff -U8 timezones_before_update.dump timezones.dump
(Assignee)

Comment 8

8 years ago
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.
Assignee: nobody → dbo.moz
Status: NEW → ASSIGNED
Attachment #409348 - Flags: review?(ssitter)
(Assignee)

Comment 9

8 years ago
(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
(Reporter)

Comment 10

8 years ago
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       -

Updated

8 years ago
Attachment #409348 - Flags: review?(ssitter) → review+

Comment 11

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

r=ssitter
(Assignee)

Comment 12

8 years ago
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).
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
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".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.