474632 - Update internal timezone database to version 2009a

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[Stefan Sitter [:ssitter]]

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

Comment 1

[Daniel Boelzle [:dbo]]

Attachment: patch - v1

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.

Comment 2

[Daniel Boelzle [:dbo]]

Attachment: patch - v2

now with bumped version

Comment 3

[Daniel Boelzle [:dbo]]

Attachment: diff -U8 timezones_before_update.dump timezones.dump

diff of sqlite changes

Comment 4

[Stefan Sitter [:ssitter]]

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?

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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: ???

Comment 6

[Stefan Sitter [:ssitter]]

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

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 8

[Daniel Boelzle [:dbo]]

Attachment: patch - v3

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.

Comment 9

[Stefan Sitter [:ssitter]]

Comment on attachment 359489 [details] [diff] [review]
patch - v3

r=ssitter

Comment 10

[Daniel Boelzle [:dbo]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/198927925c91>

-> FIXED

Comment 11

[Stefan Sitter [:ssitter]]

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

Comment 12

[Daniel Boelzle [:dbo]]

AFAIK tzcode(zic) is different form vzic. I haven't found any updates/fixes for vzic.

Comment 13

[Sebastian Schwieger]

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/

Comment 14

[Daniel Boelzle [:dbo]]

It's still good ol' vzic 1.3 :/