Time format error in Olson TZ rules for Asia

yoshito_umaoka at us.ibm.com yoshito_umaoka at us.ibm.com
Tue Apr 27 14:22:38 UTC 2010

kre at 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 at dc37a.
> nci.nih.gov>
>     Message-ID: 
<996D816825CFEA469870126E9050D3F0E1F8DE6E at 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 
> is taking to get implementations recognising the 24:00 value in the 
> 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 
> 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 
> 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...


- year 2011, 2016...


(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.


More information about the tz mailing list