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