Update internal timezone database to version 2009f

RESOLVED FIXED in 1.0b1

Status

defect
RESOLVED FIXED
11 years ago
8 years ago

People

(Reporter: ssitter, Assigned: dbo)

Tracking

Trunk
1.0b1

Details

Attachments

(2 attachments, 2 obsolete attachments)

Olson timezone database has been released in new version:

announcement of 2009b: <http://article.gmane.org/gmane.comp.time.tz/2582>
announcement of 2009c: <http://article.gmane.org/gmane.comp.time.tz/2598>
announcement of 2009d: <http://article.gmane.org/gmane.comp.time.tz/2616>

download: <ftp://elsie.nci.nih.gov/pub/>
Flags: wanted-calendar1.0?
announcement of 2009e: <http://article.gmane.org/gmane.comp.time.tz/2650>
Summary: Update internal timezone database to version 2009d → Update internal timezone database to version 2009e
Posted patch patch - v1 (obsolete) — Splinter Review
timezone has been updated: America/Argentina/San_Luis
timezone has been updated: America/Havana
timezone has been updated: Asia/Amman
timezone has been updated: Asia/Damascus
timezone has been updated: Asia/Gaza
timezone: Pacific/Wallis    [t]ake over as is or use [a]lias? t


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



DONE.
Assignee: nobody → dbo.moz
Status: NEW → ASSIGNED
Attachment #371735 - Flags: review?(ssitter)
Posted file sqlite dump diff (obsolete) —
Attachment #371735 - Flags: review?(ssitter) → review-
Comment on attachment 371735 [details] [diff] [review]
patch - v1

Sorry for the late review.

- calendar/timezones/config/version.txt is not updated

- I don't see changes for Africa/Casablanca, Africa/Tunis in the patch that I see when diffing tzdata2009a with tzdata2009e?

- What does "timezone: Pacific/Wallis [t]ake over as is or use [a]lias? t" mean? I don't see anything related in the patch.

- tzdata2009f has been released by now, could you update?

Nit: Please do the next diff old > new instead of new > old. That way I don't have to bend my brain that much ;)

OT: Is there a solution to create timezones.sqlite on Windows development environment?
(In reply to comment #4)
> - I don't see changes for Africa/Casablanca, Africa/Tunis in the patch that I
> see when diffing tzdata2009a with tzdata2009e?
Hmm, I don't see changes to Casablanca looking at africa in tzdata. Could you please elaborate?

> - What does "timezone: Pacific/Wallis [t]ake over as is or use [a]lias? t"
> mean? I don't see anything related in the patch.
There's been a timezone for Pacific/Wallis in former times. Since we need to support this in upcoming versions (some storage.sdb/local.sqlite might still refer to it), the script asks whether to just take over the VTIMEZONE definition or to alias it with a different name (in case there's a definition of course).

> - tzdata2009f has been released by now, could you update?
will do

> OT: Is there a solution to create timezones.sqlite on Windows development
> environment?
I expect the xpcshell (js) script to work equally good on msys/Windows, because it runs in the usual build env. Creating the zones.tab etc, I assume you've compiled vzic 1.3 on Windows.
Summary: Update internal timezone database to version 2009e → Update internal timezone database to version 2009f
Changes needed for /Users/dbo/moz_cc/src/calendar/locales/../timezones/../../calendar/locales/en-US/chrome/calendar/timezones.properties:
---
---


timezone has been updated: America/Argentina/San_Luis
timezone has been updated: America/Havana
timezone has been updated: Asia/Amman
timezone has been updated: Asia/Damascus
timezone has been updated: Asia/Gaza
timezone: Pacific/Wallis    [t]ake over as is or use [a]lias? t


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



DONE.
Attachment #371735 - Attachment is obsolete: true
Attachment #373698 - Flags: review?(ssitter)
Attachment #373698 - Attachment is obsolete: true
Attachment #373698 - Flags: review?(ssitter)
Attachment #373699 - Attachment mime type: application/octet-stream → text/plain
Attachment #373698 - Attachment is obsolete: false
Attachment #373698 - Flags: review?(ssitter)
Attachment #371737 - Attachment is obsolete: true
> Hmm, I don't see changes to Casablanca looking at africa in tzdata. 
> Could you please elaborate?

Timezone "Africa/Casablanca" uses rule "Morocco". In the diff I see that new DST start (Jun 1) and end dates (Aug 21) for 2009 were added to this rule. I'd expect to see the changes in the created ical string. But maybe this is a different topic that should be investigated.
Comment on attachment 373698 [details] [diff] [review]
patch - v2 to 2009f

r=ssitter
Attachment #373698 - Flags: review?(ssitter) → review+
(In reply to comment #8)
> > Hmm, I don't see changes to Casablanca looking at africa in tzdata. 
> > Could you please elaborate?
> 
> Timezone "Africa/Casablanca" uses rule "Morocco". In the diff I see that new
> DST start (Jun 1) and end dates (Aug 21) for 2009 were added to this rule. I'd
> expect to see the changes in the created ical string. But maybe this is a
> different topic that should be investigated.

Yes, I see. I suspect this is either a shortcoming of vzic 1.3 or that we generate the data for OL compat (omitting --pure); haven't investigated further.
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/7cc4a30ab955>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: wanted-calendar1.0?
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.