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

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu Feb 15 13:12:47 2007

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.

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.

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

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.

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.

Cheers,
Bernard

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Feb 15 14:36:42 2007

> 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 (????).

> I was also able to find "VTIMEZONE" examples on the Internet which

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

> I propose we clarify that DTSTART always specify a onset date-time

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.

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

> 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: [email-masked], 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/

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu Feb 15 17:43:01 2007

Hi Reinhold,

Reinhold Kainhofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> is actually later.

You are mistaken.

Here's from section 4.6.5 of RFC 2445:

   The mandatory "DTSTART" property gives the effective onset date and
   local time for the time zone sub-component definition.

and also:

   "TZOFFSETFROM" is combined with "DTSTART" to define the effective
   onset for the time zone sub-component definition.

and then later:

    - The "DTSTART" and the "TZOFFSETTO" properties MUST be used
    when generating the onset date-time values (instances) from the
    RRULE.

> Compare this also with the example given in section "4.6.5 

The example you are quoting contains a mistake. The DTSTART specified
in the DAYLIGHT sub-component is actually a copy'n'paste of the DTSTART
specified in the STANDARD sub-component. The DTSTART in the DAYLIGHT
sub-component was supposed to be set to 19970406T02000, that is, the
same value as RDATE. This has been fixed since draft -01 of rfc2445bis.

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

Right, but only because it is erroneous as mentionned above.

> DAYLIGHT and a STANDARD with the same DTSTART.

No.

> be defined to either not take effect at any time or forever...

No.

> not define an onset date.

Can you please specify which part of RFC 2445 brought you to believe
all of this?

Thanks,
Bernard

> If implementations out there do it differently, 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> 
> iD8DBQFF1OA8TqjEwhXvPN0RAmfvAKCLY1n1ho8M1DlZ42iAGI1Nuf9AnwCgp0J5
> cenbhO/IL3ap3qTgT1VhfjQ=
> =PVE8
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify