[Ietf-calsify] Section 4.6.5 Time Zone Component: DTSTART always an onset date-time of an observance?

[Reinhold Kainhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Donnerstag, 15. Februar 2007 schrieb Bernard Desruisseaux:
> In section 4.6.5 Time Zone Component of RFC 2445 it says:
>  > If specified, the onset for the observance defined by the time zone
>  > sub-component is defined by either the "RRULE" or "RDATE" property.
>
> If the sub-component specifies "RDATE" properties and no "RRULE"
> property, is the "DTSTART" property still considered as a onset
> date-time?  I would sure hope so.

Actually, I don't think so. The DTSTART is the date when the whole DST 
definition comes into effect. E.g. when the EU harmonized the DST 
regulations, that date would be the DTSTART, but the first onset of DAYLIGHT  
is actually later. Compare this also with the example given in section "4.6.5 
Time Zone Component" of rfc 2445:
     BEGIN:DAYLIGHT
     DTSTART:19971026T020000
     RDATE:19970406T020000
     TZOFFSETFROM:-0500
     TZOFFSETTO:-0400
     TZNAME:EDT
     END:DAYLIGHT

Here, oct 26, 1997 is the date when the whole DST regulation came into effect, 
but the first DST occurred already a few months earlier (????).


> The "STANDARD" and "DAYLIGHT" examples in the draft always duplicate
> the value of "DTSTART" in a "RDATE" property. Which I think should be
> superfluous.  I noticed that the the "VTIMEZONE" generated by "vzic"
> always duplicate the value of "DTSTART" in a "RDATE" property, but
> I was also able to find "VTIMEZONE" examples on the Internet which
> do not.

Hehe, a simple look at RFC 2445 would have gotten you one ;-)

> I propose we clarify that DTSTART always specify a onset date-time
> of an observance.

I would rather clarify that DTSTART does NOT specify an onset date, but rather 
the date when the regulation came into effect. Thus, there are typically a 
DAYLIGHT and a STANDARD with the same DTSTART.

> Then, in the same paragraph the text goes one with:
>  > If neither is specified, only one sub-component can be specified in
>  > the "VTIMEZONE" calendar component and it is assumed that the single
>  > observance specified is always in effect.
>
> If I understand this correctly, if a "VTIMEZONE" component defines
> a "STANDARD" or "DAYLIGHT" sub-component with only the "DTSTART"
> property, than it ?must? (requirement level not clear) be the only
> sub-component defined in the "VTIMEZONE" component. I have no clue
> why there is such a restriction.

Because the DTSTART does not introduce an onset date, so that component has to 
be defined to either not take effect at any time or forever...

> Again, I was able to find "VTIMEZONE" examples that specify both
> "STANDARD" and "DAYLIGHT" sub-components with each only the
> "DTSTART" property.
>
> I propose that we remove this restriction.

We should at least clarify it. RFC 2445 clearly means that the DTSTART does 
not define an onset date. If implementations out there do it differently, 
we'll have to clarify that.

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF1OA8TqjEwhXvPN0RAmfvAKCLY1n1ho8M1DlZ42iAGI1Nuf9AnwCgp0J5
cenbhO/IL3ap3qTgT1VhfjQ=
=PVE8
-----END PGP SIGNATURE-----