If there are no string changes, maybe we can slip this in for Lightning 3.3 ?
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.
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.
Is there any approximate date of release?
Hello guys, any news on this update?
When will the new release be issued?
Fortunately local timezone data base has well known format (SQLite). So as a workaround you can adjust it yourself.
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.
(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?
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?
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.
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.
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)?
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.
(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.
2015a was released: https://mm.icann.org/pipermail/tz-announce/2015-January/000028.html
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.
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.
@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.
Filed bug 1129963 "Timezone database being static part of the calendar leads to users having out of date timezone definitions"
Fixed by bug 1129857?
Yes I'd say so.
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.