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
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
