dtstart and date vs datetime

[Dan Connolly]

I just discovered that some code I wrote will produce this:
2006-08-04T::

Given this input:

DTSTART:20060804

Seems like my testing would have caught a bug like that
long ago... but maybe it's not so much a bug as bad data.
The default datatype for DTSTART is DATE-TIME, and
all my tests explicitly give a type in the case of DATE:

DTSTART;VALUE=DATE:20060804

The sections on DTSTART and DATETIME are reasonably
clear that DTSTART:20060804 is no good...
http://www.w3.org/2002/12/cal/rfc2445#sec4.8.2.4

But there's a DTSTART:19980205 example discussed in passing
under 4.8.6.3 Trigger
and another DTSTART:19971102

Those examples seem to still be there in the October 11, 2005 draft
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-00.txt

So... what's the deal?
  - these examples are bad data and should be fixed

  - the specification of DTSTART should be updated so that
    the default type depends on the value given

  - the specification of the DATE-TIME data type should be
    updated so that values like 19971102 are OK

p.s. there isn't a calisfy test repository yet, is there?
I participate in development of hCalendar test develompent.
  http://microformats.org/wiki/hcalendar-tests

... RDF calendar test development.
  http://www.w3.org/2002/12/cal/test/
  http://www.w3.org/2002/12/cal/#dev

I hope to get those two more sync'd up.

In particular, whatever answer I get from the CALSIFY WG on
this issue, I intend to reflect in those 2 test suites.

--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

[Eliot Lear]

Hi Dan,

I'm a little confused by your message.  On the one hand, you're confused
by what also appears to me to be a broken example in §4.8.6.3.  It seems
to me that you found a bug, and that the example should at least
indicate "VALUE=DATE".  On the other hand, I don't understand how you
ended up with the following:

Dan Connolly wrote:
> I just discovered that some code I wrote will produce this:
> 2006-08-04T::
>
> Given this input:
>
> DTSTART:20060804
>  
Under what circumstances do you end up with either a dash ("-") in the
date specification or a pair of colons ("::")?

Thanks,

Eliot

[Dan Connolly]

On Sun, 2006-04-23 at 11:15 +0200, Eliot Lear wrote:
> Hi Dan,
>
> I'm a little confused by your message.  On the one hand, you're confused
> by what also appears to me to be a broken example in §4.8.6.3.  It seems
> to me that you found a bug, and that the example should at least
> indicate "VALUE=DATE".

That's one of the three options I can see. I guess I don't really
like it, though. It seems to me that the cat is out of the bag
and this syntax should be supported. Perhaps not, though.

>   On the other hand, I don't understand how you
> ended up with the following:
>
> Dan Connolly wrote:
> > I just discovered that some code I wrote will produce this:
> > 2006-08-04T::
> >
> > Given this input:
> >
> > DTSTART:20060804
> >  
> Under what circumstances do you end up with either a dash ("-") in the
> date specification or a pair of colons ("::")?

Ah... yes, I should have explained... my code converts iCalendar
datetimes to XML Schema datatype datetimes of the
form YYYY-MM-DDTHH:MM:SS.

> Thanks,
>
> Eliot
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

[Dan Connolly]

On Fri, 2006-04-21 at 12:55 -0500, Dan Connolly wrote:
[...]

> The sections on DTSTART and DATETIME are reasonably
> clear that DTSTART:20060804 is no good...
> http://www.w3.org/2002/12/cal/rfc2445#sec4.8.2.4
>
> But there's a DTSTART:19980205 example discussed in passing
> under 4.8.6.3 Trigger
> and another DTSTART:19971102
>
> Those examples seem to still be there in the October 11, 2005 draft
> http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-00.txt
>
> So... what's the deal?
>   - these examples are bad data and should be fixed
>
>   - the specification of DTSTART should be updated so that
>     the default type depends on the value given
>
>   - the specification of the DATE-TIME data type should be
>     updated so that values like 19971102 are OK

I see a 2006-10-04 edit that adopts the 1st suggestion.
http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-03.html#rfc.change.edit-02.82

Thanks.

I haven't put test cases together yet, but I hope to soon.

> p.s. there isn't a calisfy test repository yet, is there?
> I participate in development of hCalendar test develompent.
>   http://microformats.org/wiki/hcalendar-tests
>
> ... RDF calendar test development.
>   http://www.w3.org/2002/12/cal/test/
>   http://www.w3.org/2002/12/cal/#dev
>
> I hope to get those two more sync'd up.
>
> In particular, whatever answer I get from the CALSIFY WG on
> this issue, I intend to reflect in those 2 test suites.
>

--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

[brycenesbitt]

Suggestion for improvement:

The PRODID filed is used inconsistently through the iCal spec.  No
wonder: it is unclear how the string should be put together.  While
referencing ISO 9070 is OK, that's a challenging specification to look
up.  A summary in the iCal spec would help.

I just checked the October 2006 draft, and this section is unchanged
from the original.

                            -Bryce Nesbitt