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

Tue Jun 9 14:26:06 PDT 2009

Hi Bernard,

Thanks for your response to my query - originally posted to 
ietf-calsify at osafoundation.org.  I assume I was posting to the wrong 
place, as I received a couple of new invites to ietf.org mailing lists 
(Thank you to whoever initiated that).

Ok, I think I understand that now.  Wording of these things is really 
tricky!
A possible re-phrasing might be :

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 UTC offset associated with "DTSTART" is
specified in the "TZOFFSETFROM" property.

The mandatory "TZOFFSETFROM" property gives the UTC offset which
is in use immediately before the onset of this time zone observance begins.

For example, the following represents  the time at which the observance
of Standard Time took effect in Fall 1967 for New York City:

...

Regards,
Gren.

On 9/6/09 20:08, Bernard Desruisseaux wrote:
> 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
>