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

RESOLVED FIXED in 4.0.0.1

Status

Calendar
Internal Components
P2
normal
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: martinschroeder, Assigned: darktrojan)

Tracking

Trunk
4.0.0.1

Details

(Whiteboard: [timezone])

Attachments

(1 attachment)

2014c: http://mm.icann.org/pipermail/tz-announce/2014-May/000020.html
If there are no string changes, maybe we can slip this in for Lightning 3.3 ?
(Reporter)

Updated

3 years ago
Assignee: nobody → mschroeder
Status: NEW → ASSIGNED
Summary: Update internal timezone database from version 2014b to version 2014c → Update internal timezone database from version 2014b to version 2014d
(Reporter)

Comment 2

3 years ago
2014d: http://mm.icann.org/pipermail/tz-announce/2014-May/000021.html
(Reporter)

Comment 3

3 years ago
2014e: http://mm.icann.org/pipermail/tz-announce/2014-June/000022.html
Summary: Update internal timezone database from version 2014b to version 2014d → Update internal timezone database from version 2014b to version 2014e
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.
Summary: Update internal timezone database from version 2014b to version 2014e → Update internal timezone database from version 2014b to version 2014f
(Reporter)

Comment 5

3 years ago
2014g: http://mm.icann.org/pipermail/tz-announce/2014-August/000024.html
Summary: Update internal timezone database from version 2014b to version 2014f → Update internal timezone database from version 2014b to version 2014g
(Reporter)

Comment 6

3 years ago
2014h: http://mm.icann.org/pipermail/tz-announce/2014-September/000025.html
Summary: Update internal timezone database from version 2014b to version 2014g → Update internal timezone database from version 2014b to version 2014h
(Reporter)

Comment 7

3 years ago
2014i: http://mm.icann.org/pipermail/tz-announce/2014-October/000026.html
Summary: Update internal timezone database from version 2014b to version 2014h → Update internal timezone database from version 2014b to version 2014i

Updated

3 years ago
Blocks: 1090039

Updated

3 years ago
Blocks: 1090082

Comment 8

3 years ago
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.
No longer blocks: 1090039, 1090082

Updated

3 years ago
Blocks: 1090039, 1090082

Comment 9

3 years ago
Is there any approximate  date of release?

Comment 10

3 years ago
Hello guys, any news on this update?

Comment 11

3 years ago
When will the new release be issued?

Comment 12

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

Comment 13

3 years ago
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

3 years ago
Any updates?

Comment 15

3 years ago
2014j: http://mm.icann.org/pipermail/tz-announce/2014-November/000027.html
Summary: Update internal timezone database from version 2014b to version 2014i → Update internal timezone database from version 2014b to version 2014j

Comment 16

3 years ago
(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

3 years ago
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.
Martin, do you think you have time to look into this?
Flags: needinfo?(mschroeder)
(Reporter)

Comment 19

3 years ago
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.
Flags: needinfo?(mschroeder)
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

3 years ago
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

3 years ago
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

3 years ago
(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

3 years ago
2015a was released: https://mm.icann.org/pipermail/tz-announce/2015-January/000028.html
Summary: Update internal timezone database from version 2014b to version 2014j → Update internal timezone database from version 2014b to version 2015a

Updated

3 years ago
No longer blocks: 1090039

Comment 25

3 years ago
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.
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

3 years ago
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

3 years ago
@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 ;)
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

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

Comment 31

3 years ago
Fixed by bug 1129857?
Yes I'd say so.
Assignee: mschroeder → geoff
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.0
(Assignee)

Comment 33

3 years ago
Created attachment 8563856 [details]
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.
You need to log in before you can comment on or make changes to this bug.