[uf-discuss] all day events

[Mark Mansour]

Thanks for informing me of the eventual decision - it is appreciated.
I'm glad you've gone for the shortened version too.

Mark

On 6/13/06, Ryan King <ryan at technorati.com> wrote:
> 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
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>


-- 
picking the lint off your life