1009894 - Update internal timezone database from version 2014b to version 2015a

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect, P2)

Description

[Martin Schröder [:mschroeder]]

2014c: http://mm.icann.org/pipermail/tz-announce/2014-May/000020.html

Comment 1

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

If there are no string changes, maybe we can slip this in for Lightning 3.3 ?

Comment 2

[Martin Schröder [:mschroeder]]

2014d: http://mm.icann.org/pipermail/tz-announce/2014-May/000021.html

Comment 3

[Martin Schröder [:mschroeder]]

2014e: http://mm.icann.org/pipermail/tz-announce/2014-June/000022.html

Comment 4

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

2014f: http://mm.icann.org/pipermail/tz-announce/2014-August/000023.html

A lot of changes here that affect historical data. Please read carefully before blindly selecting [t]ake over as is or use [a]lias.

Comment 5

[Martin Schröder [:mschroeder]]

2014g: http://mm.icann.org/pipermail/tz-announce/2014-August/000024.html

Comment 6

[Martin Schröder [:mschroeder]]

2014h: http://mm.icann.org/pipermail/tz-announce/2014-September/000025.html

Comment 7

[Martin Schröder [:mschroeder]]

2014i: http://mm.icann.org/pipermail/tz-announce/2014-October/000026.html

Comment 8

[Stefan Sitter [:ssitter]]

When fixing this bug we need to consider to port it back to Lightning 3.3.x. Users are already complaining because of the outdated timezone information.

Comment 9

[Dmitry Monakhov]

Is there any approximate  date of release?

Comment 10

[Alexander T]

Hello guys, any news on this update?

Comment 11

[Kitoboy]

When will the new release be issued?

Comment 12

[Dmitry Monakhov]

Fortunately local timezone data base has well known format (SQLite). So as a workaround you can adjust it yourself.

Comment 13

[Anton Derbenev]

unfortunately most of users of this are not tech specialists, so could not do that (without will and 2-3 months of acquiring knowledge and skills).

There is another workaround though, - to select another timezone; it our case (Moscow was +4, became +3), Kaliningrad works, because it was and stays UTC+3.


Also, I think it's bad that Lightning uses separate database permanently. All moderns OSes have tzdata or analogue (regstry values in windows: http://msdn.microsoft.com/en-us/library/windows/desktop/ms725481.aspx), so it would be great if Lightning would not carry its own database, but generate it from system values instead (on 1st start) and check periodically (like once per month). Then, even if db gets outdated, fix would be simple reinstall of lightning (simple for non-techy users), or removal of cache-db to get it regenerated.

Comment 14

[Aleksandr]

Any updates?

Comment 15

[Stefan Sitter [:ssitter]]

2014j: http://mm.icann.org/pipermail/tz-announce/2014-November/000027.html

Comment 16

[ilya.dergalin]

(In reply to Dmitry Monakhov from comment #12)
> Fortunately local timezone data base has well known format (SQLite). So as a
> workaround you can adjust it yourself.
This is a valid workaround for technical and semi-technical users. To make it more easily implementable can you please provide [semi-exact] commands to update?

Comment 17

[Dmitry Monakhov]

Here 
https://bugzilla.mozilla.org/attachment.cgi?id=8512472
you can find time zone database with right Moscow time Zone.

To edit time zone file manually I use (FireFox + SQLight Manager).
You should edit tz_data table.

You can simply replace distribution file by the new one and restart Thunderbird.
Bad news that  you need  repeat the procedure in the case of lightning upgrade until the bug will be fixed.

Comment 18

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

Martin, do you think you have time to look into this?

Comment 19

[Martin Schröder [:mschroeder]]

Philipp, I prepared the timezone data for 2014i with vzic but got stuck with our make target for the timezone update because it is not automatically included in the build process (and therefore not in the objdir) and after doing it manually (generating a valid Makefile) I encountered the following situation:

ms-mbp:timezones mschroeder$ make update=/Users/mschroeder/vzic-1.3/zoneinfo-2014i
/Users/mschroeder/Repositories/comm-central/config/config.mk:103: backend.mk: No such file or directory
/Users/mschroeder/Repositories/comm-central/config/rules.mk:1322: *** /Users/mschroeder/Repositories/comm-central/calendar/timezones contains a jar.mn file but this file is not declared in a JAR_MANIFESTS variable in a moz.build file.  Stop.

During the week I had no time to have a look at the problem (had it once before, but cannot remember how I solved it). I'll give it another try this weekend.

Comment 20

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

Thanks for taking a look. Maybe we should switch the update code to a python script instead, that would make things easier in the future.

Comment 21

[Slipeer]

Is here any working instructions how to update timezones.sqlite database?
Instructions from calendar/timezones/Makefile.in don't work for me.
Or can anybody provide world-wide actual timezones.sqlite database (not only Europe/Moscow)?

Comment 22

[Merlyel]

2 Slipeer
$ sqlite timezones.sqlite
update tz_data set component='BEGIN:VTIMEZONE
TZID:Asia/Yekaterinburg
X-LIC-LOCATION:Asia/Yekaterinburg
BEGIN:STANDARD
TZOFFSETFROM:+0500
TZOFFSETTO:+0500
TZNAME:YEKT
DTSTART:19700101T000000
END:STANDARD
END:VTIMEZONE
' where TZID like 'Asia/Yek%' ;
You need to change TZOFFSETFROM and TZOFFSETTO. And don't forget to put newline at the end or there gonna be problems. Also, backup your current timezones.sqlite.

Comment 23

[Slipeer]

(In reply to Merlyel from comment #22)
> 2 Slipeer
> $ sqlite timezones.sqlite

Thank you, this I understand.
But I have users in more than one or two time zones of Russia.
Therefore, looking for instructions on how to update the data on timezones.sqlite for all timezones.

Comment 24

[Stefan Sitter [:ssitter]]

2015a was released: https://mm.icann.org/pipermail/tz-announce/2015-January/000028.html

Comment 25

[Eugene Crosser]

If calendar is a package in an OS distribution (such as in Ubuntu), it does not get updated between releases of the distribution. Consequently, users may not get the update of the timezone database for years. This is hardly acceptable.

Could it be possible to make calendar use OS-wide timezone database instead? Such system-wide database is typically updated more frequently.

Comment 26

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

I think we have a bug open for that, and now that there has been some work on making the timezone database simpler we may be able to make some progress on it.

Comment 27

[Stefan Sitter [:ssitter]]

I see that Bug 1129857 was opened today. But the change from this bug cannot be applied to current stable release Lightning 3.3. It should be discussed if those users have to live with wrong event information due to incorrect timezone data until release of Lightning 4.0.

Comment 28

[Eugene Crosser]

@Philipp, I cannot find the bug to which you refer in comment 26. Could you please write the number here in a comment for reference? (so we can upvote it ;)

Comment 29

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

As we currently don't release the timezones extension, we'd have to do another release Lightning 3.3.4 to update the timezones there. As long as there are no string updates and its just a matter of dropping in a new timezones.sqlite, I can easily do this manually.

I did a quick search and I couldn't find a bug for it either, its been on my mind more than once though. Feel free to file one.

Comment 30

[Eugene Crosser]

Filed bug 1129963 "Timezone database being static part of the calendar leads to users having out of date timezone definitions"

Comment 31

[Magnus Melin [:mkmelin]]

Fixed by bug 1129857?

Comment 32

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

Yes I'd say so.

Comment 33

[Geoff Lankow (:darktrojan)]

Attachment: calendar-timezones-1.2015a.xpi

This is an SQLite version of the timezones extension for 2015a. I created it by extracting the data from the JSON version into timezones.sqlite. I've also changed the application versions and set the strictCompatibility flag, to disable the extension once the user upgrades Thunderbird.

Hopefully this is a suitable solution for those of you who need it. I'm not making promises about any further updates.