Closed Bug 504299 Opened 10 years ago Closed 6 years ago

Asia/Jerusalem DST record is erroneous in timezones.sqlite.

Categories

(Calendar :: Internal Components, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: yonatanhak, Assigned: martinschroeder)

References

()

Details

(Whiteboard: [timezone])

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: From 0.8 to nightly 20090708

Sync with other calendars (such as Google) has a 1 hour offset. Reason being that there is no DST information in the original record: 
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
X-LIC-LOCATION:Asia/Jerusalem
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0200
TZNAME:IST
DTSTART:19700101T000000
END:STANDARD
END:VTIMEZONE


Reproducible: Always

Steps to Reproduce:
1. Create an event in Google calendar
2. Sync it with the "provider for Google calendar"
3. 
Actual Results:  
The event listed in Lightning is one hour before the actual time.

Expected Results:  
The event in Lightning should be the same time as in Google calendar (or any external calendar for that matter).

timezones.sqlite database should be corrected as follows.
1. Open tz_data table
2. Go to the tzid record Asia/Jerusalem and open it.
3. Select the component field and change its content to:
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
X-LIC-LOCATION:Asia/Jerusalem
BEGIN:STANDARD
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:IST
DTSTART:20081005T020000
RDATE;VALUE=DATE-TIME:20081005T020000,20090927T020000,20100927T020000,20111002T020000,
20120923T020000,20130908T020000,20140928T020000,20150920T020000,20161009T020000,
20170924T020000,20180916T020000,20191006T020000,20200927T020000,20210912T020000,
20221002T020000,20230924T020000,20241006T020000,20250928T020000,20260920T020000,
20271010T020000,20280924T020000,20290916T020000,20301006T020000,20310921T020000,
20320912T020000,20331002T020000,20340917T020000,20351007T020000,20360928T020000,
20370913T020000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20090327T020000
RDATE;VALUE=DATE-TIME:20090327T020000,20100326T020000,20110401T020000,20120330T020000,
20130329T020000,20140328T020000,20150327T020000,20160401T020000,20170331T020000,
20180330T020000,20190329T020000,20200327T020000,20210326T020000,20220401T020000,
20230331T020000,20240329T020000,20250328T020000,20260327T020000,20270326T020000,
20280331T020000,20290330T020000,20300329T020000,20310328T020000,20320326T020000,
20330401T020000,20340331T020000,20350330T020000,20360328T020000,20370327T020000
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
TZNAME:Jerusalem DST
END:DAYLIGHT
END:VTIMEZONE

This correction is true until 2037...
Sources for creating the above fix:

A table with Jerusalem DST until 2037
http://home.tiscali.nl/~t876506/TZworld.html#mea

Date calculator for the DST start time:
http://home.tiscali.nl/~t876506/WhatDay.html

VTIMEZONE syntax description:
http://www.kanzaki.com/docs/ical/vtimezone.html
Please note that we use tzdata as the source for this data. As my Linux machines are switching to DST in the right moment, I guess this is happen in Sunbird because of using old tzdata file or integration problem. 

I know about some users (including myself) who are affected by this issue also on Linux -> Confirming issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The data in timezones.sqlite is automatically created from Olson timezone database. See Bug 484877 for previous and Bug 500244 for next upgrade. 

Maybe the Olson timezone database input is faulty, maybe the creation process is faulty? I don't know. The creation process seems to work only on Linux but I'm running Windows and therefore can't check.
I'm unable to access the FTP address of tzdata but I have 2009j on my Linux (at /usr/share/zoneinfo/Jerusalem). Since it is binary data, how do I make sure if 2009j is indeed right for our location? I guess it is, but since the Israeli government have not changed dst settings recently, I am afraid it is not the only cause to this issue and we'd need to verify it.
yonatanhak - Can you please post here the timezone settings before you did your changes? 

As for my previous message, I've found we can query the zoneinfo database by the following command - 
  zdump -v /usr/share/zoneinfo/Asia/Jerusalem | grep 2009
My DST timezone settings are listed in the beginning of the bug report.
(In reply to comment #6)
> My DST timezone settings are listed in the beginning of the bug report.

And the original one? It is required in order to allow comparing your changes to the provided definition file.
Stefan - Thank you for the information. I think it shows the source of the problem.
Asia/Jerusalem is not maintained in the Olson timezone database. Instead they have added IST (Israel Standard Time), which holds an accurate up-to-date settings of the Israeli DST.
Lightning on the other hand does not have the IST time zone. In order to resolve this issue I suggest:
- Insert IST into Lightning timezone.
- Rename Asia/Jerusalem to "Asia/Jerusalem is deprecated, Use IST instead"
Stefan - Thank you for the information. I think it shows the source of the
problem.
Asia/Jerusalem is not maintained in the Olson timezone database. Instead they
have added IST (Israel Standard Time), which holds an accurate up-to-date
settings of the Israeli DST.
Lightning on the other hand does not have the IST time zone. In order to
resolve this issue I suggest:
- Insert IST into Lightning timezone.
- Rename Asia/Jerusalem to "Asia/Jerusalem is deprecated, Use IST instead"
The DST handling for Jersualem causes problem also when reciving invitation for
this time-zone. When accepting the invitation the meeting is set one hour
earlier than the actual time.
This Bug is related to Bug 473915
Please hurry up to find what causing this issue, as in less than a week from now it will become more complicated to reproduce (IL removes the DST flag this Saturday).
(In reply to comment #12)
> Please hurry up to find what causing this issue, as in less than a week from
> now it will become more complicated to reproduce (IL removes the DST flag this
> Saturday).

Tomer - Look at comment #9.

All info comes from Olsen Timezone database. For some (Political?) reason, Asia/Jerusalem was separated from Israel. The problem is that IST is not a timezone recognized by anyone. The solution is to call the guy who invented "IST" and ask him for the good of all to clone these changes into Asia/Jerusalem.
(In reply to comment #13)
> The solution is to call the guy who invented
> "IST" and ask him for the good of all to clone these changes into
> Asia/Jerusalem.

Do you know who's that guy?

Please keep in mind that we would prefer a standard solution which will require zero configurations from the user side. We might even pop this issue to Olsen maintainers as a fault, because since Jerusalem is (currently, at least) an Israeli territory, this is what should appear as the Asia/Jerusalem timezone.
At the bellow link the time for Asia/Jerusalem is given correctly, including DST

http://twiki.org/cgi-bin/xtra/tzdate?tz=Asia/Jerusalem

The data is suppose to come fro Olsen data-base.
To add to confusion IST is used for two time-zones
a) Israel Standard time (IDT when DST)
b) Indian Standard time
(In reply to comment #16)
> To add to confusion IST is used for two time-zones
According to wikipedia, it even more complicated to use IST - 

[IST stands for] Any of a number of time zones:

    * Indian Standard Time
    * Iran Standard Time
    * Irish Standard Time
    * Israel Standard Time

http://en.wikipedia.org/wiki/IST
So, after some investigation I have to clarify the situation:
In software application the common zone names (composed of continent and city) are used instead of abbreviated, sometimes duplicated timezone identifiers. This is also what Lightning and Sunbird use. I don't know how "IST" came into play here. Fact is that our timezones database generated from the Olson one seems to have not all up-to-date timezone information. It's possible that there's a bug in the update script which generates the database. I'll have to find some time this week to look into this.
@Martin: FYI
- I am still using the (quite old, there's no newer version I know of) vzic 1.3 to generate the zones info.
- We don't pass the |pure| parameter (w.r.t. OL compatilibity).
- IIRC we encountered flaws in vzic 1.3 when dealing with multiple rules some time ago (maybe Stefan remembers the bug?).
Since we have switched to DST again recently, this issue is relevant again, and users are complaining on this issue on our community forum (here is the most recent thread - http://mozilla.org.il/board/viewtopic.php?t=8798). 

Please let me know how we can help in order to get this fixed before the next release.
I have further investigated the issue. The chain which lead to the DST information in Lightning is as follows:

1. Olson - Has correct information.
2. vzic utility extracts the information from Olson into separate timezone definition files as text. I have checked the vzic translation for Asia/Jerusalem and found it to be correct.
3. Lightning translation of the timezone records into timezones.sqlite is found in the following directory of Lightning sources: calendar/timezones. A file named update.js is responsible for the conversion, and IMHO it is not doing it right.

I lack any knowledge of Javascript so I cannot further debug it, but the issue is not Olson or vzic as I and others suspected before.

Will someone with js know how take the burden?
(In reply to comment #21)
> 2. vzic utility extracts the information from Olson into separate timezone
> definition files as text. I have checked the vzic translation for
> Asia/Jerusalem and found it to be correct.

Yonatanhak, could you please assure that the above is really correct regarding how we generate the VTIMEZONEs (i.e. calling vzic in OL compat mode *without* --pure)? IIRC the OL compat mode specifically is causing the loss since Jerusalem has multiple sections which OL cannot cope with.
We generate the timezones.sqlite right out of vzic's VTIMEZONEs without any loss (via libical).
(In reply to comment #22)
> (In reply to comment #21)
> > 2. vzic utility extracts the information from Olson into separate timezone
> > definition files as text. I have checked the vzic translation for
> > Asia/Jerusalem and found it to be correct.
> 
> Yonatanhak, could you please assure that the above is really correct regarding
> how we generate the VTIMEZONEs (i.e. calling vzic in OL compat mode *without*
> --pure)? IIRC the OL compat mode specifically is causing the loss since
> Jerusalem has multiple sections which OL cannot cope with.
> We generate the timezones.sqlite right out of vzic's VTIMEZONEs without any
> loss (via libical).

I will check again and return ASAP.
(In reply to comment #22)
> (In reply to comment #21)
> > 2. vzic utility extracts the information from Olson into separate timezone
> > definition files as text. I have checked the vzic translation for
> > Asia/Jerusalem and found it to be correct.
> 
> Yonatanhak, could you please assure that the above is really correct regarding
> how we generate the VTIMEZONEs (i.e. calling vzic in OL compat mode *without*
> --pure)? IIRC the OL compat mode specifically is causing the loss since
> Jerusalem has multiple sections which OL cannot cope with.
> We generate the timezones.sqlite right out of vzic's VTIMEZONEs without any
> loss (via libical).

Oh... Indeed w/o --PURE you get an erroneous result from vzic. Daniel, can you fix vzic or use it's --PURE output?
I am not sure whether vzic is doing anything wrong in that area (it has flaws, e.g. does not process the latest Olson data, but this is another bug/topic). Looking at the "pure" output it would unnecessarily bloat ics calendars and iMIP being sent out. So I suspect we're quite happy with the condensed VTIMEZONEs.
(In reply to comment #25)
> I am not sure whether vzic is doing anything wrong in that area (it has flaws,
> e.g. does not process the latest Olson data, but this is another bug/topic).
> Looking at the "pure" output it would unnecessarily bloat ics calendars and
> iMIP being sent out. So I suspect we're quite happy with the condensed
> VTIMEZONEs.

But this leaves Asia/Jerusalem w/o DST. This makes us very un-happy.. :-(
Can't you insert an override for special cases like this one? Maybe add some code to the timezone update utility of Lightning, to read a complementary "override file". I guess that there are many other ways to solve it.
Flags: wanted-calendar1.0?
We recently updated to 2010i with a new vzic version. Does this still happen with 1.0b2pre nightlies?
Philipp, as I can see, the latest vzic version is still 1.3 and wasn't updated since 2006-08-23. Its fork, tzurl, produces the same OL compatible output (which does not contain Asia/Jerusalem DST information), while being executed without the "--pure" option.
We have recently tested Lightning with the patched timezones.sqlite version (the one which does contain local DST info), and it worked perfectly. Synchronization with Google Calendar resulted in correct event times.
So I may only suggest you to include Asia/Jerusalem (and perhaps, some other problematic timezones as well) DST info in your timezones.sqlite separately at the build step.
Can anyone be kind enough as to upload an already patched version of timezones.sqlite until a stable release of lightning is released?

The version I've produced, had some inconvenient side effects with synced calendars.

Thanks!
Dmitriy, thanks for the input. Unfortunately we are too shortly before a release to do this change now, especially since its high risk. The code freeze is today. The next release will be in about 4 months.

We probably need to change the timezone update architecture in some way to do so. I hope we can take care of this for next time.

In the long run we might want to store the pure version in the timezone database and emit the condensed mode in exports, itip messages, etc. We'll have to test this for performance though.
Thank you, Philipp, that is a possible option. I suppose, caching both pure and condensed VTIMEZONEs in the timezone database may solve the performance issue.

Dotan, you may find the patched timezones.sqlite version here - http://www.4shared.com/file/Y27Yf7bT/timezones.html
If you're aware of some more convenient way to share this file with others, please, be kind to do so.
thank you Dmitriy!

Works like a charm.

For a more permanent location, I've uploaded the file to my website's server, at the following address:

http://www.dotanmazor.com/files/timezones.sqlite

Let's hope that it will be treated soon enough, during a formal release.

Dotan
Duplicate of this bug: 569086
Duplicate of this bug: 576856
(In reply to comment #32)
> thank you Dmitriy!
> 
> Works like a charm.
> 
> For a more permanent location, I've uploaded the file to my website's server,
> at the following address:
> 
> http://www.dotanmazor.com/files/timezones.sqlite
> 
> Let's hope that it will be treated soon enough, during a formal release.
> 
> Dotan

Where do I need to put this file, in order to fix the problem?
TIA,
Y.
Yaniv, all you have to do is to replace your original timezones.sqlite file with the modified one. Usually, this database file is located under your lightning extension directory, which is under your user thunderbird dir (e.g. ~/.thunderbird/m0t0p15x.default/extensions/{lightning extension hash}/ on my Gentoo installation). Just try to search for timezones.sqlite file in case your system is using some different path conventions.

In order to fix this problem in general, the lightning distributors should take some appropriate steps discussed above.
Dmitriy or anyone else, what are the fix instructions for the windows platform? I have no timezones.sqlite on my machine, anywhere.
Thanks,
Idan.
Idan,

The timezones.sqlite that I'm using, is located in the following folder:
C:\Users\USERNAME\AppData\Roaming\Thunderbird\Profiles\7hhee23.default\extensions\{e2fda1a4-762b-4020-b5ad-a41df1933103}

You need to save the file in this location.

I would recommend closing Thunderbird before that, and backing up before proceeding.

Dotan
Duplicate of this bug: 456521
this works, as it does fix the daylight saving issue, however, after updating the timezones files from the above link, The existing local calendar does not open any more (simply vanishes from the list of calendars), and when I try to create a new local calendar, after entering the name and pressing NEXT, nothing happens (it just stays in the same wizard dialog as if I didn't press the NEXT at all).
Obviously, there's something it does not like from the timezone file, since if I restore the original one, this problem disappears, but the daylight save issue is back of course. The timezone I downloaded is also much smaller then the one installed by lightning.
Thunderbird 3.1.9
Lightning 1.0b3pre, provider for Google Calendar 0.7pre (downloaded a daily build yesterday).
(In reply to comment #40)
Lightning 1.0b3pre contains a new version of the timezone database (Bug 632149). If you replace it by some old version it will probably break Lightning. Please only use the database matching the Lightning version.
That's sort of what happened, but my Gmail calendar works fine. I rather have the Gmail calendar and no local Calendars then a Calendard where every meeting is moved by an hour. 
Is there any way to get an updated timezone that DOES contain the timezone fix (or something that will let me use the IST zone in Thunderbird/Lightning)?
Are there any estimates on when this will be fixed? (it's "only" open for 1.5 years now...)
This issue is important to us, and blocking people in Israel from using Lightning. Please pay attention to this issue, and let us know what information is missing to resolve this issue.

Thanks.
So with --pure, the timezone definition for Asia/Jerusalem is 187 lines. This means every calendar using Asia/Jerusalem will have this set of lines extra, even the exported ones. Here's the pro/cons:

Pro full definition (--pure):
* DST works (strong argument :)

Con full definition:
* Exported calendar files might not be imported into other apps
* Invitations sent to outlook users might cause outlook to say its unparseable
* Possible performance loss due to more complex rule.

Could someone using the modified database please test the mentioned use cases with outlook? Windows Mail might also be interesting, maybe also other apps like Evolution.
Duplicate of this bug: 669093
(In reply to comment #44)
> Could someone using the modified database please test the mentioned use
> cases with outlook? Windows Mail might also be interesting, maybe also other
> apps like Evolution.
If we are sure that our approach is right and Microsoft does it wrong, do we have some contacts in Microsoft that might be able to give us some constructive suggestions?
Tried to replace the timezones.sqlite with the one downloaded from http://www.dotanmazor.com/files/timezones.sqlite

All calenders stopped working, local and google. (local not shown in list of calenders at all, google shows in list, but no events)

I'm using Lightning 1.0b4 on thunderbird 5.0
That's odd - I did exactly that two days ago and it worked like a charm. I'm on Ubuntu 11.04 - maybe it matters somehow.

What DIDN'T work for me was the kind instructions posted at mozilla.org.il about manually modifying the SQLite database - it seemed to get me back to UTC but I might have done it wrong.
I'm on windows 7. File-location: C:\Users\nathan\AppData\Roaming\Thunderbird\Profiles\a8biswoz.default\extensions\{e2fda1a4-762b-4020-b5ad-a41df1933103}
Nathan, I tried it too and found out that you're right.

This is a very weird thing, since I was working with it to begin with, and it was probably altered during time.

If anyone manages to produce such a file again, I will be able to replace the non-functioning file in the link, to the new file.

Dotan
******************
NOTE TO EVERYBODY:
******************
There are so many people following this bug, and only 9 votes.

Please vote for the bug.

Thanks.
Dotan
(In reply to Nathan Rona from comment #47)
> Tried to replace the timezones.sqlite with the one downloaded from
> http://www.dotanmazor.com/files/timezones.sqlite
> 
> All calenders stopped working, local and google. (local not shown in list of
> calenders at all, google shows in list, but no events)
> 
> I'm using Lightning 1.0b4 on thunderbird 5.0

It works on Lighting 1.0b5 - using the sqlite file from the above URL, and changing the sqlite version to 1.2011b according to:
http://bugzilla.mozilla.org/show_bug.cgi?id=669406

Both local and google have the correct time now.
requesting block flag. 

Please fix this issue as soon as possible, as it make Lightning calendar useless to local people unless they find information about this issue and install the timezone hacks on their application.

Searching in Google for 'lightning timezone Jerusalem' and similar keywords give other conversations about this issue which we are not aware of. Can someone please spend some time and try to index them here?
Flags: blocking-calendar1.0?
(In reply to Liav from comment #52)
> (In reply to Nathan Rona from comment #47)
> > Tried to replace the timezones.sqlite with the one downloaded from
> > http://www.dotanmazor.com/files/timezones.sqlite
> > 
> ...
> It works on Lighting 1.0b5 - using the sqlite file from the above URL, and
> changing the sqlite version to 1.2011b according to:
> http://bugzilla.mozilla.org/show_bug.cgi?id=669406

Liav,

Thank you for the tip.

There's still 1 question that remains unanswered: how does one change the timezones.sqlite version by himself?

Can you give a short step-by-step reference, so that I can update the on-line file?

Thanks!

Dotan
(In reply to Dotan Mazor from comment #54)
> 
> Liav,
> 
> Thank you for the tip.
> 
> There's still 1 question that remains unanswered: how does one change the
> timezones.sqlite version by himself?
> 
> Can you give a short step-by-step reference, so that I can update the
> on-line file?
> 
> Thanks!
> 
> Dotan

Liav's method works great on TB5 for Linux!

The timezone version is saved in a field called "version" in the "tz_version" table.
Changing its value from 1.2010i to 1.2011b works as expected and DST is now calculated correctly.

I've uploaded a patch version to:
http://www.wupload.com/file/101453314/timezones.sqlite
Thanks Assaf 

Works great, now I'll start using Lightning again.

Pleas fix this in official release as well.
I still have a problem with the latest version Lightning 1.0b5 and TB 6.0.1.

Before the patch, all invitations received by email were off by 1 hour. when saved to calendar off by 2 hours.

After the patch, invitations appear correctly in the email. However, after save to calendar, they are off by 3 hours.

Viktor
Please note that this bug is very major to every Lightning user in Israel, and we need someone to get it fixed. Soon Ubuntu would switch to Thunderbird by default, and I expect to see a boost in the number of complains here from Linux users (mostly enterprise users). 



If you see discussions on this topic in other sites, please paste here links to these discussions.
I'd still like to see some testing as mentioned in comment 44. If we use the working (pure) definition, then each event containing a Jerusalem will contain an extra 187 lines of timezone definitions. This means on every caldav event on the server, every invitation, every exported calendar, ...

I know you want something that "just works", but is this the right way to go?
Duplicate of this bug: 473915
I've made the 2011n version of the timezones database (bug 647232) contain the pure version of Asia/Jerusalem. Lets see what happens when we distribute it...
For those of you who do not want to wait until Lightning 1.1, here is the timezones extension. Be aware that installing this will upgrade timezones on your database and due to bug 406579 you will no longer be able to use Lightning 1.0 without the timezones extension. This should be fixed for Lightning 1.1.
First of all, many thanks for fixing this bug, which has been a major issue for users is in Israel. 

I think that most users are not in a rush to update as we have gone into winter time by now. It will be an issue again only in the spring as we are approaching the DST again.
Actually I don't think we should postpone it, it is still an issue since events are stored as a delta of GMT so if someone makes an appointment today to a date which will have wrong DST then when the fix will apply the meeting will be shifted, am I wrong?
I did not mean to say that it should be postponed. What I meant was the for most users it will probably be ok to wait until 1.1, and thus will not install the time-zones extension referred to in comment 62.

I think you're right that if you make appointment in date with DTS you will get on wrong time.
I have a similar problem with Moscow Timezone (which was recently changed from GMT+3/GMT+4 to GMT+4). I have to set Asia/Dubai in settings: if I set Europe/Moscow it fires reminder one hour *after* event.
Are you using the latest version? I believe we updated timezones in the meanwhile.
I'm not sure which is the latest Lighting version compatible with Thunderbird 3.1.19 (latest version available in Ubuntu 10.04). I'm using version 1.0b2.
Sorry, you will need to use a newer version of Thunderbird, I think at least Thunderbird 10.
Isn't 3.1.19 stable? Do you support this version? Unfortunately, there are no newer versions available in Ubuntu 10.04 LTS for the moment.
No, we don't support Lightning 1.0b2 anymore due to lack of support and developer resources. See this ppa for more details: https://launchpad.net/~mozillateam/+archive/thunderbird-stable
According to https://support.mozillamessaging.com/en-US/kb/thunderbird-31-end-life-faq Thunderbird 3.1 is supported until April 24, 2012. Am I right that Lighting and Thunderbird have different support cycles?
I'd like to point out that the VTIMEZONE definition in this report contains an failure:

One STANDARD RDATE is wrong: 20100927T020000 -> 20100927T020000

This is the corrected definition:
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
X-LIC-LOCATION:Asia/Jerusalem
BEGIN:STANDARD
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:IST
DTSTART:20081005T020000
RDATE;VALUE=DATE-TIME:20081005T020000,20090927T020000,20100912T020000,20111002T020000,
20120923T020000,20130908T020000,20140928T020000,20150920T020000,20161009T020000,
20170924T020000,20180916T020000,20191006T020000,20200927T020000,20210912T020000,
20221002T020000,20230924T020000,20241006T020000,20250928T020000,20260920T020000,
20271010T020000,20280924T020000,20290916T020000,20301006T020000,20310921T020000,
20320912T020000,20331002T020000,20340917T020000,20351007T020000,20360928T020000,
20370913T020000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20090327T020000
RDATE;VALUE=DATE-TIME:20090327T020000,20100326T020000,20110401T020000,20120330T020000,
20130329T020000,20140328T020000,20150327T020000,20160401T020000,20170331T020000,
20180330T020000,20190329T020000,20200327T020000,20210326T020000,20220401T020000,
20230331T020000,20240329T020000,20250328T020000,20260327T020000,20270326T020000,
20280331T020000,20290330T020000,20300329T020000,20310328T020000,20320326T020000,
20330401T020000,20340331T020000,20350330T020000,20360328T020000,20370327T020000
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
TZNAME:Jerusalem DST
END:DAYLIGHT
END:VTIMEZONE
> I'd like to point out that the VTIMEZONE definition in this report contains an failure:
> One STANDARD RDATE is wrong: 20100927T020000 -> 20100927T020000

I assume you meant 20100912T020000. I checked the timezone definitions shipped with Lightning 1.6 and it contains 20100912T020000 not 20100927T020000 -> no problem. Maybe your release of Lightning is out of date?
You are right, my fault, sorry. The definition I pasted however contains the correct 20100912T020000.

And yes, I have an outdated version...
According to Comment 61 the Asia/Jerusalem timezone definition was fixed in Lightning 1.1.

Is there any reason to keep this bug open?
I guess we can open a new bug for it, but back then I changed the definition manually just for Asia/Jerusalem. The goal would be to automate it even more so either both pure and full definition is packaged and used in the right locations or at least have something automatically package the right version based on some rule.
Whiteboard: [timezone]
(In reply to Philipp Kewisch [:Fallen] from comment #77)
> I guess we can open a new bug for it, but back then I changed the definition
> manually just for Asia/Jerusalem. The goal would be to automate it even more
> so either both pure and full definition is packaged and used in the right
> locations or at least have something automatically package the right version
> based on some rule.

I found a patch to vzic in the libical repository that seems to automatically package the right version. I'll try this for my upcoming patch to the timezone data (tz2013c).
Closing this bug for now. Please reopen if someone forgets to package the right version of Asia/Jerusalem in the future.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Flags: wanted-calendar1.0?
Flags: blocking-calendar1.0?
The Israeli Daylight dates have changed (again), and therefore the timezones table is wrong again. The policy is: "daylight starts at the first Sunday that comes before the last Friday of March" (does anyone know how to express that as an RRULE?) and "daylight ends at the last Sunday of October".
So, the timezones.sqlite should contain:
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
X-LIC-LOCATION:Asia/Jerusalem
BEGIN:STANDARD
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:IST
DTSTART:19421101T000000
RDATE;VALUE=DATE-TIME:19421101T000000,19431101T000000,19441101T000000,19451101T020000,19461101T000000,19481101T020000,19491101T020000,19500915T030000,19511111T030000,19521019T030000,19530913T030000,19540912T000000,19550911T000000,19560930T030000,19570922T000000,19741013T000000,19750831T000000,19850915T000000,19860907T000000,19870913T000000,19880903T000000,19890903T000000,19900826T000000,19910901T000000,19920906T000000,19930905T000000,19940828T000000,19950903T000000,19960916T000000,19970914T000000,19980906T000000,19990903T020000,20001006T010000,20010924T010000,20021007T010000,20031003T010000,20040922T010000,20051009T020000,20061001T020000,20070916T020000,20081005T020000,20090927T020000,20100912T020000,20111002T020000,20120923T020000,20131027T020000,20141026T020000,20151025T020000,20161030T020000,20171029T020000,20181028T020000,20191027T020000,20201025T020000,20211021T020000,20221030T020000,20231029T020000,20241027T020000,20251026T020000,20261025T020000,20271031T020000,20281029T020000,20291028T020000,20301027T020000,20311026T020000,20321031T020000,20331030T020000,20341029T020000,20351028T020000,20361026T020000,20371025T020000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
TZNAME:IDT
DTSTART:19400601T000000
RDATE;VALUE=DATE-TIME:19400601T000000,19430401T020000,19440401T000000,19450416T000000,19460416T020000,19490501T000000,19500416T000000,19510401T000000,19520420T020000,19530412T020000,19540613T000000,19550611T020000,19560603T000000,19570429T020000,19740707T000000,19750420T000000,19850414T000000,19860518T000000,19870415T000000,19880409T000000,19890430T000000,19900325T000000,19910324T000000,19920329T000000,19930402T000000,19940401T000000,19950331T000000,19960315T000000,19970321T000000,19980320T000000,19990402T020000,20000414T020000,20010409T010000,20020329T010000,20030328T010000,20040407T010000,20050401T020000,20060331T020000,20070330T020000,20080328T020000,20090327T020000,20100326T020000,20110401T020000,20120330T020000,20130329T020000,20140328T020000,20150327T020000,20160325T020000,20170324T020000,20180323T020000,20190329T020000,20200327T020000,20210326T020000,20220325T020000,20230324T020000,20240329T020000,20250328T020000,20260327T020000,20270326T020000,20280324T020000,20290323T020000,20300329T020000,20310328T020000,20320326T020000,20330325T020000,20340324T020000,20350323T020000,20360328T020000,20370327T020000
END:DAYLIGHT
END:VTIMEZONE

Mind that the original daylight time should have ended by the end of this week, while it will expire only at the end of October.
Ah, they should have done it earlier. Strings won't be in time for the release in case they've changed in the latest timezone data, either we will have to create a hacked together package, ask the localizers for late-l10n, or release another version 6 weeks later.

Matthew, Martin, could one of you look into this?
http://mm.icann.org/pipermail/tz-announce/2013-July/000012.html
http://www.iana.org/time-zones

I think we should repackage the timezone database into an addon, and repackage it automatically with each new release of the database instead of the software.
(In reply to Philipp Kewisch [:Fallen] (unavailable until September 5th) from comment #79)
> Closing this bug for now. Please reopen if someone forgets to package the
> right version of Asia/Jerusalem in the future.

Reopening because of tzdata2013d.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Philipp, taking over... which branches should this land on?
Assignee: nobody → mschroeder
Status: REOPENED → ASSIGNED
Martin, thanks! Are there string changes involved? If not, then we could shove this into beta if it lands before the 10th. If so, I guess we will have to go for central only and figure out a strategy for after the release.
Attachment #799840 - Attachment mime type: text/x-patch → text/plain
Attached patch Patch v1 (obsolete) — Splinter Review
Attachment #799842 - Flags: review?(philipp)
Attachment #799842 - Flags: approval-calendar-release?(philipp)
Attachment #799842 - Flags: approval-calendar-beta?(philipp)
Attachment #799842 - Flags: approval-calendar-aurora?(philipp)
Comment on attachment 799842 [details] [diff] [review]
Patch v1

No need to push on release, Lightning 2.6 is on the beta tree now. r=philipp

Thanks for the quick turnaround!
Attachment #799842 - Flags: review?(philipp)
Attachment #799842 - Flags: review+
Attachment #799842 - Flags: approval-calendar-release?(philipp)
Attachment #799842 - Flags: approval-calendar-release-
Attachment #799842 - Flags: approval-calendar-beta?(philipp)
Attachment #799842 - Flags: approval-calendar-beta+
Attachment #799842 - Flags: approval-calendar-aurora?(philipp)
Attachment #799842 - Flags: approval-calendar-aurora+
Attached patch Patch v1.1Splinter Review
Added header for not checking in the patch by myself.
Attachment #799842 - Attachment is obsolete: true
Attachment #799985 - Flags: review+
Attachment #799985 - Flags: checkin?
Attachment #799985 - Flags: approval-calendar-beta+
Attachment #799985 - Flags: approval-calendar-aurora+
Comment on attachment 799985 [details] [diff] [review]
Patch v1.1

Just use the checkin-needed keyword in the future, please.
Attachment #799985 - Flags: checkin? → checkin+
Target Milestone: --- → 2.6
Same story again:
The time will be changed on Oct 26, whereas thunderbird 31.1.2 (ubuntu 14.04, up to date) thinks it changed sometime last week.

zdump -v /etc/localtime |grep 2014
/etc/localtime  Thu Mar 27 23:59:59 2014 UT = Fri Mar 28 01:59:59 2014 IST isdst=0 gmtoff=7200
/etc/localtime  Fri Mar 28 00:00:00 2014 UT = Fri Mar 28 03:00:00 2014 IDT isdst=1 gmtoff=10800
/etc/localtime  Sat Oct 25 22:59:59 2014 UT = Sun Oct 26 01:59:59 2014 IDT isdst=1 gmtoff=10800
/etc/localtime  Sat Oct 25 23:00:00 2014 UT = Sun Oct 26 01:00:00 2014 IST isdst=0 gmtoff=7200
You need to log in before you can comment on or make changes to this bug.