[ietf-calsify] DTSTART in VTIMEZONE STANDARD and DAYLIGHT sub-components - localtime, but which localtime?

[Gren Elliot]

Hi,

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 
(http://sourceforge.net/projects/freeassociation/)

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 :
      .../zoneinfo/Europe/Zurich.ics

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 :

BEGIN:VTIMEZONE
TZID:/freeassociation.sourceforge.net/Tzfile/Europe/Zurich
X-LIC-LOCATION:Europe/Zurich
BEGIN:STANDARD
TZNAME:CET
DTSTART:19701025T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:CEST
DTSTART:19700328T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE

The only difference (apart from component and property ordering) from 
the old version is that the DTSTART in the STANDARD component used to be :
     DTSTART:19701025T030000
and in the DAYLIGHT component it used to be :
     DTSTART:19700329T020000
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 3.8.2.4 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
       time value.

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.

Thoughts?

Regards,
Gren Elliot

P.S.
http://www.timeanddate.com/worldclock/city.html?n=268
says that
DST started 
<http://www.timeanddate.com/worldclock/clockchange.html?n=268> on 
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...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20090609/1990bb56/attachment.htm