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

[Bernard Desruisseaux]

Hi Gren,

See Section 3.6.5. Time Zone Component:

 > 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 mandatory "TZOFFSETFROM" property gives the UTC offset which
 > is in use when the onset of this time zone observance begins.
 > "TZOFFSETFROM" is combined with "DTSTART" to define the effective
 > onset for the time zone sub-component definition.  For example,
 > the following represents the time at which the observance of
 > Standard Time took effect in Fall 1967 for New York City:
 >
 >   DTSTART:19671029T020000
 >
 >   TZOFFSETFROM:-0400

Cheers,
Bernard


Gren Elliot wrote:
> 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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> ietf-calsify mailing list
> ietf-calsify at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify