Closed Bug 474632 Opened 12 years ago Closed 12 years ago
Update internal timezone database to version 2009a
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
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)
now with bumped version
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.
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.
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 :/
You need to log in before you can comment on or make changes to this bug.