[uf-discuss] all day events

[Ryan King]

Its been a long time, but I want to tie up this loose end.

I quote the entire email below, just for context, but I'm gonna reply  
up here.

Long story short, Mark, I think you were right, we should keep things  
simpler with dates. Previously we'd been padding all dates to full  
datetimes, though it had never been specified that this was required.

Brian's recently made changes to a bunch of the hcalendar tests to  
make the date's more sane [http://hg.microformats.org/tests? 
cs=5e956386a971].

We still need to specify this in the parsing document, so that its  
clearer.

thanks Mark,
ryan


On Feb 16, 2006, at 3:45 AM, Mark Mansour wrote:
>> You're right there is a date type, but we ignore it for good reason.
>> Sorry that I took me awhile to respond, but I couldn't remember at
>> first the exact reason for the way we do it.
>
> Hey, not a problem.
>
>> Anyway, the reason we confound the DATE and DATETIME types is that
>> they are treated essentially the same by calendaring applications.
>> For example, I just created an event in Apple's iCal.app for 2/6-2/9
>> (last week), then exported it:
>
>>> BEGIN:VCALENDAR
>>> VERSION:2.0
>>> X-WR-CALNAME:blah
>>> PRODID:-//Apple Computer\, Inc//iCal 2.0//EN
>>> X-WR-RELCALID:4BA2A3D9-23D1-495E-BFA2-AA439939BF0C
>>> X-WR-TIMEZONE:America/Los_Angeles
>>> CALSCALE:GREGORIAN
>>> METHOD:PUBLISH
>>> BEGIN:VEVENT
>>> DTSTART;VALUE=DATE:20060206
>>> DTEND;VALUE=DATE:20060209
>>> SUMMARY:blah
>>> UID:26F9A96A-5D25-455A-8240-12EED1ADF63C
>>> SEQUENCE:4
>>> DTSTAMP:20060214T070829Z
>>> END:VEVENT
>>> END:VCALENDAR
>>
>> Notice that, though I created the event as ending on 2006-02-08, it
>> put 2006-02-09, making 2006-02-09 == 2006-02-09T00:00.
>
> I'm not really clear on the argument you are making here.  I see two
> issues with your statement (a - that calendaring programs like the
> Apple one do understand both dates and datetimes; and b - that you've
> said the end date is both the 8th and the 9th in your example (and I
> do understand the idea that end dates are exclusive)) - but this isn't
> really what I was trying to convey.
>
> Let me try to restate the issue again in a different way, maybe it
> will clear things up.
>
> I reckon:
> - 2006-02-09 is a date
> - 2006-02-09T00:00 is a 'floating' datetime
> - semantically (sorry, I don't like that word) 2006-02-09 ==  
> 2006-02-09T00:00
> - but 2006-02-09T00:00 is the ugly way of saying 2006-02-09
> - the hcard-parsing page says "For properties which take an ISO8601
> datetime value, parsers *should* pad any necessary precision (e.g.
> seconds) and *should* normalize any datetimes with timezone offsets"
> - since there is no timezone, none should be present in the final date
> (or datetime)
>
> therefore the proper way to write 2006-02-09 is 2006-02-09T00:00:00.
>
> In my blog entry I was asserting that is was neater to write the
> datetime simply as a date - that was a big portion of my blog entry -
> perhaps not as clearly expressed as it should have been.  Again, I
> just think 2006-02-09 is neater.
>
> For the sake of all of those concerned (who have even bothered to read
> this far) that we agree on, as you said earlier, that (drumroll
> please)
> --->    2006-02-09 == 2006-02-09T00:00:00
>
> Therefore it would be nice to add clarification to the hcard- 
> parsing spec saying
> - all dates information should be expressed as datetimes
> - 'all day events' *may* be represented without a timezone, if they
> are a floating time (as described in rfc2445), but *should* have the
> hour, minute and second represented as 00:00:00
>
> Phew.
>
> Mark