[ietf-calsify] DTSTART in VTIMEZONE STANDARD and DAYLIGHT sub-components - localtime, but which localtime?
gren.elliot at scalix.com
Tue Jun 9 08:40:40 PDT 2009
I'm looking for clarification as to what localtime means inside a
STANDARD or DAYLIGHT component in the context of the value to assign to
DTSTART, and also hoping that draft-ietf-calsify-rfc2445bis-10 will get
updated to make it clearer in this area. Specifically, if the localtime
is changing from 2am to 3am at the onset time for a VTIMEZONE
sub-component, should DTSTART reflect the 2am time or the 3am time?
I've ended up thinking about this because I'm in the process of testing
out the latest libical code for our use
With our previous cut of the libical code, timezone information
corresponding to, say, Europe/Zurich used to come from one of libical's
own files :
The new code appears to work from a combination of
/usr/share/zoneinfo/zone.tab and /usr/share/zoneinfo/Europe/Zurich -
which are part of the linux system "tzdata" package. Great, I thought.
I can rely on the OS to keep the timezone info up to date. However, the
timezone I'm getting from this differs from the timezone I used to get.
This is the new version :
The only difference (apart from component and property ordering) from
the old version is that the DTSTART in the STANDARD component used to be :
and in the DAYLIGHT component it used to be :
i.e. The opposite way around to the above...
Looking at http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-10
Section 3.6.5, you get this description of what DTSTART should look like
in a VTIMEZONE (section 22.214.171.124 on DTSTART in isolation is similar) :
The mandatory "DTSTART" property gives the effective onset date
and local time for the time zone sub-component definition.
"DTSTART" in this usage MUST be specified as a date with local
The problem with this is that there are 2 fairly common sense ways of
thinking about what the localtime is at this point. If I want to know
when to change my clock from STANDARD to DAYLIGHT time, I wait until the
time of the change in STANDARD time (say 2am) and spring my clock
forward to 3am at that point.
If, however, I'm looking at the DAYLIGHT component, I'm tempted to think
that localtime for that instant is the localtime in the DAYLIGHT
component - i.e. 3am.
This difference in view seems consistent with the difference between the
new and old VTIMEZONE definitions, however I haven't noticed anything
yet which shouts out which is correct.
Sunday, 29 March 2009, 02:00 local standard time
DST ends <http://www.timeanddate.com/worldclock/clockchange.html?n=268>
on Sunday, 25 October 2009, 03:00 local daylight time
which would imply that the time is the time just before the onset, which
would imply a world view where the old code was correct.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ietf-calsify