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

From: Gren Elliot <[email-masked]>
Date: Tue, 9 Jun 2009 16:40:40 +0100

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
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 09 Jun 2009 15:08:07 -0400

Hi Gren,

See Section 3.6.5. Time Zone Component:

 > 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:
> ------------------------------------------------------------------------
>

---

From: Gren Elliot <[email-masked]>
Date: Tue, 9 Jun 2009 22:26:06 +0100

Hi Bernard,

Thanks for your response to my query - originally posted to 
[email-masked].  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:
>> 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 
>> corresponding to, say, Europe/Zurich used to come from one of 
>> libical's own files :
>> 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.
>>
>> 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) :
>> 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.
>> DST ends 
>> 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.
>>
>>

---

From: Gren Elliot <[email-masked]>
Date: Tue, 9 Jun 2009 22:26:06 +0100

Hi Bernard,

...

Regards,
Gren.

---

From: Gren Elliot <[email-masked]>
Date: Tue, 9 Jun 2009 22:26:06 +0100

Hi Bernard,

...

Regards,
Gren.

_______________________________________________
calsify mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/calsify