...perhaps we should add a little more generalisation (somehow) to handle more odd cases like this so we have distributed code that can handle it, well before any government decides to do something like

at 02:00 on the Friday after the last Thursday in March

For this particular case, I've jumped in my time machine and changed the timezone compiler so that a rule such as... Rule whatever 2010 max - Mar Fri>=26 2:00 1:00 D ...does the right thing. --ado

Date: Tue, 27 Apr 2010 10:48:19 -0400 From: lennox@cs.columbia.edu Message-ID: <19414.63795.932816.359247@irtcluster02.cs.columbia.edu> | This is correct if you interpret the "in March" part of the rule as applying | to the Friday, not the Thursday. No, ado's point was that "Fri>=26" means (one of) 26 27 28 29 30 31 1 (the 7 days that could be a Friday, and on or after the 26th of March). Whichever day is the last Thursday, the last Friday is one of the above, even if it is in April, rather than March. What's more, with appropriate calculation, this technique also gets us the 2nd Friday after the last Thursday in March (which is Apr Fri>=2 if I worked it out properly). So, we don't need an extension to handle any of those cases - I'm still pondering whether we can get all of the "Nth X before the Y" type rules that might exist without any extensions though. I'm also still considering whether it is possible to write a rule like this that works correctly at the end of February (allowing for the possibility of leap years - and without needing to revert to the isleap stuff to make a different rule for leap years than others). But wrt ... yoshito_umaoka@us.ibm.com said: | Not a small number of people use the tz database for other applications. | Of course, we should extend the rule syntax/implementation in the tz | database and code if it is really necessary. But at the same time, we | should be aware of interoperability with others, especially standard | protocols like iCalendar. Yes, I agree 100% - that's exactly why I wanted to consider this case now, and not wait until we absolutely required a change, to allow for plenty of time for others to catch up, before any data requiring the rule exists. Of course, if we don't need extensions to handle this stuff, that's even better. Does iCalendar allow the "Mar Fri>=26 00:00" trick to represent April 1, when the last Friday in March is the 25th? (That is, when the 31st is the last Thu)? kre

| For this particular case, I've jumped in my time machine and changed | the timezone compiler so that a rule such as... | | Rule whatever 2010 max - Mar Fri>=26 2:00 1:00 D | | ...does the right thing.

That's good, I didn't know that we had that ability - so the Jordan rule could be changed to use that, right? That is, your comment was more to the point that "lastFri" is not equivalent to "day after lastThu", rather than saying that we needed to retain 24:00 in the data file.

Well...the "24:00" support was introduced in 1998, while the "Fri>=26" support was introduced in 2004. So going with "24:00" makes more out-in-the-field time zone compilers happy. --ado

kre@munnari.OZ.AU wrote on 04/27/2010 02:46:12 AM:

Date: Mon, 26 Apr 2010 15:52:55 -0400 From: "Olson, Arthur David (NIH/NCI) [E]" <olsona@dc37a. nci.nih.gov> Message-ID:

<996D816825CFEA469870126E9050D3F0E1F8DE6E@NIHMLBX11.nih.gov>

| The challenge is that the end of the last Thursday of March | ("Mar lastThu 24:00") isn't always the same thing as the start of | the last Friday of March ("Mar lastFri 0:00")

We perhaps should consider extending the format even further to handle more extreme cases of things like this - we have already seen how long

it

is taking to get implementations recognising the 24:00 value in the format, though that's been in tzcode for ages now - so perhaps we should add a little more generalisation (somehow) to handle more odd cases like this so we have distributed code that can handle it, well before any government decides to do something like

at 02:00 on the Friday after the last Thursday in March

That would be (kind of) "Mar LastThu 26:00" - except we don't allow 26:00 and I don't think we should, I'd actually suggest something more like

Mar LastThu/+Fri 02:00

....

Not a small number of people use the tz database for other applications. For example, some of calendar and scheduling applications relies on the tz database to generate time zone data in iCalendar format. iCalendar [http://www.ietf.org/rfc/rfc5545.txt] represents a time zone using VTIMEZONE component. However, there is no easy way to map the rule like "Mar lastThu 24:00" to the syntax (RRULE) for now, because it does not allow hour# beyond 23. Therefore, such implementation has to expand a single rule into multiple rules - for example, - year 2010, 2012, 2013, 2014, 2015, 2017, 2018... RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1FR;BYHOUR=0 - year 2011, 2016... RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1FR;BYHOUR=0 (Note: RRULE might not make sense for the latter, because it's not repeating yearly) I do not know if IETF calendar folks are trying to resolve such case. But for now, RFC5545 is not capable to represent such recurrent rule in simple format (if my understanding is wrong, please correct). Of course, we should extend the rule syntax/implementation in the tz database and code if it is really necessary. But at the same time, we should be aware of interoperability with others, especially standard protocols like iCalendar. -Yoshito