Closed Bug 474632 Opened 12 years ago Closed 12 years ago

Update internal timezone database to version 2009a

Categories

(Calendar :: Internal Components, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ssitter, Assigned: dbo)

Details

Attachments

(2 files, 2 obsolete files)

Olson timezone database has been released in version 2009a:
  ftp://elsie.nci.nih.gov/pub/tzcode2009a.tar.gz
  ftp://elsie.nci.nih.gov/pub/tzdata2009a.tar.gz
Attached patch patch - v1 (obsolete) — Splinter Review
update log:

Changes needed for /Volumes/data/Users/dbo/moz_cc/src/calendar/timezones/../../calendar/locales/en-US/chrome/calendar/timezones.properties:
---
add    pref.timezone.Asia.Kathmandu=Asia/Kathmandu
---


timezone has been updated: America/Resolute
timezone: Asia/Katmandu    [t]ake over as is or use [a]lias? a
Please enter tzid that should be aliased with Asia/Katmandu: Asia/Kathmandu
timezone: Pacific/Wallis    [t]ake over as is or use [a]lias? t


Changes needed for /Volumes/data/Users/dbo/moz_cc/src/calendar/timezones/../../calendar/locales/en-US/chrome/calendar/timezones.properties:
---
remove pref.timezone.Asia.Katmandu=Asia/Katmandu
---



DONE.


BTW:
I've had a look at Australia/Perth (different bug) which indeed has entries to cover DST (2006/2007/2008), though those don't get it into the ics using vzic. I'm yet not sure about the cause, maybe vzic has a bug.
Assignee: nobody → daniel.boelzle
Status: NEW → ASSIGNED
Attachment #359256 - Flags: review?(ssitter)
Attachment #359256 - Attachment is obsolete: true
Attachment #359256 - Flags: review?(ssitter)
Attached patch patch - v2 (obsolete) — Splinter Review
now with bumped version
Attachment #359268 - Flags: review?(ssitter)
Attachment #359268 - Attachment is patch: true
Attachment #359268 - Attachment mime type: application/octet-stream → text/plain
diff of sqlite changes
Comment on attachment 359268 [details] [diff] [review]
patch - v2

Looks like the timezones.properties changes are missing?

Do we want a new version number like "1.2009a"? Maybe the version number could reflect the corresponding calendar version, e.g. <cal-version>.<tz-version>, 1.0.2009a?
Daniel and I were talking about this topic too today, here our results:


* Version: 2009a
  - Pro: Nice and simple, looks nice in the addons manager
  - Con: If we decide to change the schema or storage mechanism, then we are fine
    with the current tip release, (i.e just add a minVersion  2011a dependency
    to the respective tip release) but we run into problems if we want to
    support a newer timezone version for an older branch.

* Version: 1.0.2009a:
  - Pro: fits nicely with the version
  - Con: Forces us to release a new timezone package even if the timezones
    haven't changed between release numbers.

* Version: 0.1.2009a:
  - Pro: ???
  - Con: Looks very "alpha"

* Version: 1.2009a:
  - Pro: nice compromise of all. We have a schema version in there (1), it
    doesn't look beta, and we can support older releases
  - Con: ???
(In reply to comment #5)
> * Version: 1.0.2009a:
>   - Pro: fits nicely with the version
>   - Con: Forces us to release a new timezone package even if the timezones
>     haven't changed between release numbers.

I'd prefer this version but without the upgrade need or any pre-ending. If there is no new tz-extension release the version stays the same. I just thought it might be helpful to know what Sunbird/Lightning version the tz-extension was initially released for. If you see some one running e.g. (future) Sunbird 1.5 and tz-extension 1.0.2009h you'd know it is the one that was released with 1.0.
Attachment #359268 - Attachment is obsolete: true
Attachment #359268 - Flags: review?(ssitter)
It would confuse users if they have version 1.1 and see a timezone version with 1.0.2009a. They may think they have old timezone definitions if they don't understand the olson version format.

Since it might be interesting for developers, lets add a comment in the install.rdf that includes the release version.
Attached patch patch - v3Splinter Review
Sorry, I've manually played around the mq patch and refreshed before pushing it again... Here's a patch including that hunk again.

I don't think we really need a comment of the calendar version that created the timezones xpi. The timezones xpi is only data, and lightning+Sunbird (code) depends on it, not the other way round.
Attachment #359489 - Flags: review?(ssitter)
Comment on attachment 359489 [details] [diff] [review]
patch - v3

r=ssitter
Attachment #359489 - Flags: review?(ssitter) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/198927925c91>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
(In reply to comment #1)
> I've had a look at Australia/Perth (different bug) which indeed has entries to
> cover DST (2006/2007/2008), though those don't get it into the ics using vzic.
> I'm yet not sure about the cause, maybe vzic has a bug.

2009b has been released today. A post on the gmane.comp.time.tz notes:

	* zic.c: fix fencepost error
The change to zic.c will result in changed binary outputs in a handful of cases.

Don't know if this might help here. Maybe you could test it?
AFAIK tzcode(zic) is different form vzic. I haven't found any updates/fixes for vzic.
Here's where I have found vzic after some searching. Not sure if this is the latest version, but putting the link here so it gets known. Its not the location referenced in the calendar/timezones/Makefile.in which seems to be broken.

https://forgesvn1.novell.com/svn/hula/branches/hula-store/hula/import/vzic/
It's still good ol' vzic 1.3 :/
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.