datetime-design-pattern: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(added discussion from #microformats)
mNo edit summary
Line 28: Line 28:
<pre>
<pre>
Aug 18 15:16:14 <Tantek> DanC, what do you think of RFC3339?
Aug 18 15:16:14 <Tantek> DanC, what do you think of RFC3339?
Aug 18 15:16:37 <DanC> don't know it by number...
Aug 18 15:17:14 <Tantek> ISO8601 subset
Aug 18 15:17:14 <Tantek> ISO8601 subset
Aug 18 15:17:19 <DanC> Date and Time on the Internet: Timestamps http://www.ietf.org/rfc/rfc3339.txt
Aug 18 15:17:19 <DanC> Date and Time on the Internet: Timestamps http://www.ietf.org/rfc/rfc3339.txt
Line 42: Line 41:
Aug 18 15:19:28 <jcgregorio> http://bitworking.org/news/Date_Constructs_in_the_Atom_Syndication_Format
Aug 18 15:19:28 <jcgregorio> http://bitworking.org/news/Date_Constructs_in_the_Atom_Syndication_Format
Aug 18 15:21:24 <DanC> which microformat is the question coming from, Tantek ?
Aug 18 15:21:24 <DanC> which microformat is the question coming from, Tantek ?
Aug 18 15:21:35 <-- zedrdave has quit ()
Aug 18 15:23:31 <DanC> "  The grammar element time-second may have the value "60" at the end of
Aug 18 15:23:31 <DanC> "  The grammar element time-second may have the value "60" at the end of
Aug 18 15:23:31 <DanC>   months in which a leap second occurs" The XML Schema WG is in the 27th level of leap-second-hell for the past few months, I gather.
Aug 18 15:23:31 <DanC>   months in which a leap second occurs" The XML Schema WG is in the 27th level of leap-second-hell for the past few months, I gather.
Line 52: Line 50:
Aug 18 15:26:58 <DanC> I expect they'll use datetime fields for different things that have different cost/benefit trade-offs
Aug 18 15:26:58 <DanC> I expect they'll use datetime fields for different things that have different cost/benefit trade-offs
Aug 18 15:27:26 <DanC> do you know of any particular differences that matter to anybody?
Aug 18 15:27:26 <DanC> do you know of any particular differences that matter to anybody?
Aug 18 15:30:31 <DanC> I saw code in X2V's hCalendar for handling timezones. That seemed awfully odd, to me. Any timezone info ought to go straight from the HTML to the .ics format without the machine changing it.
Aug 18 15:30:55 <DanC> I can't think of any reason to change from local time to Z nor back in hCalendar
Aug 18 15:50:47 <Tantek> DanC, the problem is that iCalendar chose a very weird subset of ISO8601
Aug 18 15:50:53 <Tantek> and not a very easy to use one
Aug 18 15:51:00 <Tantek> and VERY poor abstraction of timezones
Aug 18 15:51:17 <Tantek> i mean, some of the most user-unfriendly, and format-space-wasteful ways to do it i've ever seen
Aug 18 15:51:18 <Tantek> so
Aug 18 15:51:37 <Tantek> in *h*Calendar, we encourage ISO8601 datetimes that are "human inspectable/verifiable"
Aug 18 15:51:53 <Tantek> which means *allowing* the datetime-0700 style of datetime
Aug 18 15:51:57 <Tantek> rather than requiring UTC
Aug 18 15:52:02 <DanC> care to elaborate on "not a very easy to use one"?
Aug 18 15:52:11 <DanC> and "poor abstraction of timezones"?
Aug 18 15:52:19 <Tantek> and then allow the conversion in X2V
Aug 18 15:52:24 <Tantek> UTC sucks
Aug 18 15:52:27 <Tantek> for human usability
Aug 18 15:52:32 <Tantek> it's that simple
Aug 18 15:52:39 <KragenSitaker> not as badly as timezone skew
Aug 18 15:52:42 <Tantek> the VTIMEZONE object is a piece of crap
Aug 18 15:53:08 <Tantek> and doesn't actually work in practice
Aug 18 15:53:19 <Tantek> because governments and other *political* bodies set timezones
Aug 18 15:53:22 <Tantek> not technical folks
Aug 18 15:53:22 <KragenSitaker> but i think 10:00:00-0700 is a perfectly reasonable solution to that problem.
Aug 18 15:53:27 <DanC> I thought hCalendar was not about redesigning iCalendar.
Aug 18 15:53:33 <KragenSitaker> first this document says "optional punctuation and optional features are bad" and then it says "you can use space instead of T if you want"
Aug 18 15:53:34 <Tantek> e.g. US DST changes coming up in 2007
Aug 18 15:53:47 <Tantek> Kragen, yes 10:00:00-0700  is a solution
Aug 18 15:53:52 <Tantek> but disallowed by iCalendar
Aug 18 15:54:05 <Tantek> DanC, we're not redesigning it
Aug 18 15:54:14 <Tantek> we're making a 1:1 translation into XHTML
Aug 18 15:54:14 <KragenSitaker> oh I see --- so you have the hoice between UTC or alphabetic timezones?
Aug 18 15:54:21 <Tantek> Kragen, correct
Aug 18 15:54:50 <KragenSitaker> i would like hCalendar to not be about redesigning iCalendar too, particularly since it's mostly going to be used at first to interface with iCalendar-supporting apps
Aug 18 15:56:21 <DanC> one can express "10:00:00 offset from UTC by 7 hours" perfectly well in iCalendar
Aug 18 15:56:33 <Tantek> my point was not expressiveness
Aug 18 15:56:36 <Tantek> my point was syntax
Aug 18 15:56:38 <Tantek> the syntax is disallowed
Aug 18 15:56:43 <KragenSitaker> RFC3339 suggests -07:00, which seems like an improvement over -0700 anyway
Aug 18 15:56:43 <KragenSitaker> RFC3339 suggests -07:00, which seems like an improvement over -0700 anyway
Aug 18 15:56:49 <Tantek> Kragen, agreed
Aug 18 15:56:49 <Tantek> Kragen, agreed
Aug 18 15:57:01 <Tantek> RFC3339 is certainly preferable to the ISO8601 subset in iCalendar
Aug 18 15:57:01 <Tantek> RFC3339 is certainly preferable to the ISO8601 subset in iCalendar
Aug 18 15:57:16 <Tantek> DanC, if all you care about is expressiveness, then you should be ok with RFC3339
Aug 18 15:57:29 <DanC> ok, but if you allow 10:00:00-07:00 in hCalendar, X2V shouldn't change it to UTC; it should change it to an always-7-hours-off timezone
Aug 18 15:57:29 <Tantek> i actually care about the syntax here
Aug 18 15:57:38 <Tantek> DanC, why?
Aug 18 15:57:51 <Tantek> (real question, I want to consider this possibility)
Aug 18 15:58:43 <DanC> hmm... I guess for an always-7-hours-off timezone, the only issue is that it simplifies the X2V code. I was thinking of "every tuesday at 2pm boston time" which can't be converted ot UTC
Aug 18 15:59:00 <Tantek> DanC, correct
Aug 18 15:59:31 <KragenSitaker> there's the additional issue of figuring out what to call that timezone.
Aug 18 16:00:31 <DanC> have you considered some syntax that uses "10:00" and "America/Chicago", Tantek?
Aug 18 16:01:20 <Tantek> DanC, "America/Chicago" depends on political judgments
Aug 18 16:01:37 <Tantek> e.g. anyone who planned a meeting in summer 2007 in America/Chicago is going to now be wrong
Aug 18 16:01:42 <Tantek> due to legislation passed
Aug 18 16:01:45 <DanC> yes, but time is in many real cases a local phenomenon
Aug 18 16:01:56 <Tantek> this is a *known* problem with using location named timezones
Aug 18 16:02:17 <DanC> no, if the meeting participants agreed to measure time relative to the government of Chicago, they're not wrong.
Aug 18 16:02:29 <Tantek> DanC, sure, but no standard supports that
Aug 18 16:02:43 <Tantek> not even iCalendar
Aug 18 16:02:47 <Tantek> what's worse is
Aug 18 16:02:56 <DanC> I suppose not. (though there's an internet draft...)
Aug 18 16:02:57 <Tantek> iCalendar provides the *illusion* of solving that
Aug 18 16:03:08 <Tantek> false precision as it were
Aug 18 16:03:15 <DanC> quite
Aug 18 16:03:28 <Tantek> DanC, no amount of internet drafts will solve this.  It's a political problem, not a technical problem.
Aug 18 16:03:46 <KragenSitaker> so anyone who planned a meeting in summer 2007 in America/Chicago, and stored the time in UTC, is now going to be wrong
Aug 18 16:03:55 <DanC> it's a political _reality_. the solution is for the city of chicago to publish its time definition.
Aug 18 16:03:56 <KragenSitaker> because the meeting will still take place at 3:00 PM local time.
Aug 18 16:04:11 <KragenSitaker> Storing the time as "15:00:00-America/Chicago" solves the problem.
Aug 18 16:04:20 <Tantek> no it doesn't
Aug 18 16:04:24 <Tantek> it appears to
Aug 18 16:04:26 <Tantek> that's the problem
Aug 18 16:04:51 <Tantek> if you have to phone in for that meeting from another location, you're pretty much screwed
Aug 18 16:04:56 <Tantek> local time zones don't really work
Aug 18 16:05:02 <KragenSitaker> sheesh
Aug 18 16:05:10 <KragenSitaker> I can't believe you said that
Aug 18 16:05:57 <DanC> Tantek's right, Kragen; iCalendar looks like it solves the local timezone problem but doesn't.
Aug 18 16:05:57 <DanC> Tantek's right, Kragen; iCalendar looks like it solves the local timezone problem but doesn't.
Aug 18 16:06:14 <DanC> and it's true that there's no standard solution to the local timezone problem
Aug 18 16:06:14 <DanC> and it's true that there's no standard solution to the local timezone problem
Aug 18 16:06:39 <Tantek> so instead of appearing to solve the problem but not solving it, we chose to provide the ability to *approximate* the local timezone using e.g. "-07:00"
Aug 18 16:06:39 <Tantek> so instead of appearing to solve the problem but not solving it, we chose to provide the ability to *approximate* the local timezone using e.g. "-07:00"
Aug 18 16:06:48 <KragenSitaker> oh, I'm not saying *iCalendar* solves the local timezone problem
Aug 18 16:06:49 <DanC> the simplest thing is to have people use Z time in hCalendar. But I gather that's unacceptably unusable?
Aug 18 16:06:49 <DanC> the simplest thing is to have people use Z time in hCalendar. But I gather that's unacceptably unusable?
Aug 18 16:06:49 <Tantek> and since that has an absolutely precise definition, if DST or whatever changes
Aug 18 16:07:11 <Tantek> then you know (and more importantly, *your software knows* to adjust local to UTC accordingly)
Aug 18 16:07:20 <Tantek> but the data is kept clean, which is important
Aug 18 16:07:35 <Tantek> DanC, yes, the simplest thing is to have everyone use UTC Z
Aug 18 16:07:35 <Tantek> DanC, yes, the simplest thing is to have everyone use UTC Z
Aug 18 16:07:38 <Tantek> However
Aug 18 16:07:38 <Tantek> However
Aug 18 16:07:41 <KragenSitaker> I'm saying that if your meeting is scheduled for 15:00, Chicago time, it's bad for your software to store it as 01:00 the next day UTC, for exactly the reason Tantek explained.
Aug 18 16:07:41 <Tantek> yes
Aug 18 16:07:50 <Tantek> it is not *nearly* as usuable/verifiable
Aug 18 16:07:50 <Tantek> it is not *nearly* as usuable/verifiable
Aug 18 16:07:55 <Tantek> as -07:00 etc.
Aug 18 16:07:55 <Tantek> as -07:00 etc.
Aug 18 16:08:02 <Tantek> hence the decision to go with the latter
Aug 18 16:08:02 <Tantek> hence the decision to go with the latter
Aug 18 16:08:12 <Tantek> some degree of human verifiability is important here
Aug 18 16:08:12 <Tantek> some degree of human verifiability is important here
Aug 18 16:08:14 <DanC> hmm... I dunno... I don't trust myself to remember whether Chicago is on -0500 or -0400 on any given day.
Aug 18 16:08:21 <KragenSitaker> It's too bad that the people of the world have not yet been enlightened about how "local time zones don't really work"
Aug 18 16:08:37 <KragenSitaker> But they're going to keep scheduling their meetings and parties and things in local time zones.
Aug 18 16:09:14 <DanC> why is that "too bad", Kragen? time has been a local phenonenon for a *lot* longer than it has been a global phenomenon. I think it's more of a miracle that UTC is usable *at all*.
Aug 18 16:09:32 <KragenSitaker> DanC: I mean, a person who believes that "local time zones don't really work" might think it's too bad.
Aug 18 16:10:54 <DanC> hmm
Aug 18 16:11:43 <KragenSitaker> I don't need "background reading" to know that if my software thinks a party is scheduled for 19:00 San Francisco time, it's going to be right, and if it thinks it's 04:00 UTC, its correctness is then dependent on political situations.
Aug 18 16:11:51 <DanC> I suppose eventually XSLT will grow a standard gmtime() function
Aug 18 16:12:03 <KragenSitaker> Since the party is, in fact, scheduledi n a local time zone, not in UTC.
Aug 18 16:12:34 <Tantek> DanC, so back to the question
Aug 18 16:12:39 <KragenSitaker> Tantek: if someone has posted a counterargument to that, feel free to send me the URL to the counterargument and I will read it.
Aug 18 16:12:40 <DanC> the screw case is: somebody asks me to join an international teleconference, and I want to know if it conflicts with picking my kid up from school, KragenSitaker
Aug 18 16:12:44 <Tantek> RFC3339 vs. xsd:dateTime?
Aug 18 16:13:18 <DanC> do you know of any observable technical differences, Tantek ? or is it just the political issue of citing IETF vs W3C specs?
Aug 18 16:13:44 <KragenSitaker> DanC: Yes, I know you have to compensate for timezone difficulties when you're comparing times.
Aug 18 16:14:21 <Tantek> DanC, my perception is that RFC3339 is a subset
Aug 18 16:14:21 <Tantek> DanC, my perception is that RFC3339 is a subset
Aug 18 16:14:24 <KragenSitaker> s/difficulties/differences/
Aug 18 16:14:56 <Tantek> DanC, you're right.  Kragen and I are used to these exchanges, having met in person and discussed them ;)
Aug 18 16:15:22 <DanC> xsd:dateTime includes "10:00:00-07:00" I'm pretty sure... I gather RFC3339 only allows Z... but I haven't finished reading...
Aug 18 16:15:34 <Tantek> no, RFC3339 allows -07:00
Aug 18 16:15:44 <Tantek> that's what I use in my Atom 1.0 feed for example :)
Aug 18 16:16:10 <DanC> seems silly to support -0700 in an internet timestamp format. odd.
Aug 18 16:16:11 <Tantek> Kragen, agreed :)
Aug 18 16:16:39 <Tantek> not silly when you consider human verifiability
Aug 18 16:17:00 <DanC>   time-numoffset  = ("+" / "-") time-hour ":" time-minute
Aug 18 16:17:00 <DanC>   time-numoffset  = ("+" / "-") time-hour ":" time-minute
Aug 18 16:17:34 <DanC> ok, then I can't see any differences. (modulo recent leap seconds issues that may affect xsd:dateTime )
Aug 18 16:17:34 <DanC> ok, then I can't see any differences. (modulo recent leap seconds issues that may affect xsd:dateTime )
Aug 18 16:17:44 <Tantek> anyway, since it looks like more reading is necessary to evaluate RFC3339 vs. xsd:dateTime, IRC may not be the best medium at this point for this discussion
Aug 18 16:17:53 <Tantek> DanC, ok
Aug 18 16:18:07 <Tantek> would be interesting to know why Atom 1.0 chose RFC3339 over xsd:dateTime
Aug 18 16:18:07 <Tantek> would be interesting to know why Atom 1.0 chose RFC3339 over xsd:dateTime
Aug 18 16:18:21 <Tantek> if there was a "real" reason or if it was arbitrary / coin-flip.
Aug 18 16:18:21 <Tantek> if there was a "real" reason or if it was arbitrary / coin-flip.
Aug 18 16:18:43 <KragenSitaker> rfc3339 is pretty short.
Aug 18 16:18:43 <KragenSitaker> rfc3339 is pretty short.
Aug 18 16:18:53 <Tantek> Kragen, that's a good point.
Aug 18 16:18:57 * Tantek likes shorter specs.
Aug 18 16:19:11 <Tantek> XSD is certainly not short by any definition.
Aug 18 16:19:19 * Tantek compares apples and truckloads of apples.
Aug 18 16:19:36 <Tantek> DanC, BTW, which came first? REC for xsd:dateTime or RFC3339?
Aug 18 16:19:36 <Tantek> DanC, BTW, which came first? REC for xsd:dateTime or RFC3339?
Aug 18 16:19:50 <DanC> RFC3339 is dated July 2002 ...
Aug 18 16:19:50 <DanC> RFC3339 is dated July 2002 ...
Line 182: Line 75:
Aug 18 16:20:47 <DanC> W3C Recommendation 02 May 2001
Aug 18 16:20:47 <DanC> W3C Recommendation 02 May 2001
Aug 18 16:22:10 <DanC> I don't see a BNF in http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ...
Aug 18 16:22:10 <DanC> I don't see a BNF in http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ...
Aug 18 16:22:27 <-- jcgregorio has quit ("Chatzilla 0.9.68a [Firefox 1.0.6/20050716]")
Aug 18 16:22:43 <KragenSitaker> yeah, appendix D of the current xml schema datatypes document seems a little scanty, actually
Aug 18 16:22:43 <KragenSitaker> yeah, appendix D of the current xml schema datatypes document seems a little scanty, actually
Aug 18 16:23:28 <DanC> ah... 2nd ed of http://www.w3.org/TR/xmlschema-2/#date is much more explicit about syntax.
Aug 18 16:23:28 <DanC> ah... 2nd ed of http://www.w3.org/TR/xmlschema-2/#date is much more explicit about syntax.
Line 193: Line 85:
Aug 18 16:25:21 <Tantek> could I ask you to summarize the pros/cons for each in a new section at end of http://microformats.org/wiki/datetime-design-pattern
Aug 18 16:25:21 <Tantek> could I ask you to summarize the pros/cons for each in a new section at end of http://microformats.org/wiki/datetime-design-pattern
Aug 18 16:25:22 <Tantek> ?
Aug 18 16:25:22 <Tantek> ?
Aug 18 16:25:33 <Tantek> (since they're your words/analysis)
Aug 18 16:25:55 <DanC> hmm... if you want my words, I'll send mail. A wiki is supposed to be the community voice, no?
Aug 18 16:25:58 <KragenSitaker> rfc 3339 is 4000 words, excluding the last two pages of boilerplate.
Aug 18 16:25:58 <KragenSitaker> rfc 3339 is 4000 words, excluding the last two pages of boilerplate.
Aug 18 16:26:10 <Tantek> DanC, you can always cite your section in the wiki
Aug 18 16:26:25 <Tantek> e.g. see that page currently
Aug 18 16:26:31 <KragenSitaker> so it's actually longer than the datetime-relevant parts of XSD but it seems much more rigorous and clear
Aug 18 16:26:31 <KragenSitaker> so it's actually longer than the datetime-relevant parts of XSD but it seems much more rigorous and clear
Aug 18 16:26:46 <Tantek> Similarly, Kragen's points are good too.
Aug 18 16:27:05 <Tantek> And statements like "rfc 3339 is 4000 words, excluding the last two pages of boilerplate" are verifiable
Aug 18 16:27:14 <Tantek> c.f. NPOV, Wikipedia
Aug 18 16:27:47 <Tantek> I think both of your points on RFC3339 vs. xsd:dateTime sound very NPOV
Aug 18 16:28:37 <DanC> my advice is: normatively cite both, and claim they specify the same syntax, and let anybody who discovers otherwise send you a bug report with a test case
Aug 18 16:28:37 <DanC> my advice is: normatively cite both, and claim they specify the same syntax, and let anybody who discovers otherwise send you a bug report with a test case
Aug 18 16:29:12 <KragenSitaker> danc: nice hack
Aug 18 16:29:12 <KragenSitaker> danc: nice hack
Aug 18 16:29:51 <Tantek> DanC, please feel free tomake that recommendation on the wiki page as well (the noratively cite both)
Aug 18 16:29:54 <Tantek> normatively even
Aug 18 16:29:57 <DanC> I'll try to dump what we discovered here in http://microformats.org/wiki/datetime-design-pattern , Tantek. not sure what priority it'll get, though.
Aug 18 16:30:09 <Tantek> totally understood
Aug 18 16:30:21 <Tantek> even some raw text with irrelevant parts edited out would be a good step
Aug 18 16:30:33 <DanC> ok
</pre>
</pre>

Revision as of 21:53, 18 August 2005

This page is a draft.

This is a page for exploring a datetime design pattern.

The pattern which is now used in hCalendar and hReview is something like this: 

<abbr class="foo" title="YYYYMMDDTHH:MM:SS+ZZZZ">Date Time</abbr>

where foo is the semantic classname which is being applied to this date/time, the title of the <abbr> is an ISO 8601 date/time and "Date Time" is a human-friendly representation of the same date/time.

This pattern is likely to be highly resuable.

--RyanKing

Can this not be viewed as a microformat in itself?

--DimitriGlazkov

It could, but inventing a microformat for the sake of inventing a microformat is against the microformat principles. If there is a specific real world problem (and uses cases) that such an elemental microformat would solve, then it would be worth considering.

Until then it is best to keep the <abbr> datetime concept merely as a microformat design pattern, to be used in _actual_ microformats that have a demonstrated practical need.

-- Tantek

Excerpt from #microformats Aug 18th. Please edit! 

Aug 18 15:16:14 <Tantek>	DanC, what do you think of RFC3339?
Aug 18 15:17:14 <Tantek>	ISO8601 subset
Aug 18 15:17:19 <DanC>	Date and Time on the Internet: Timestamps http://www.ietf.org/rfc/rfc3339.txt
Aug 18 15:17:30 <DanC>	Klyne is a good guy. I wonder if I talked with him about this.
Aug 18 15:17:32 <Tantek>	compat with W3C-NOTE-DATETIME
Aug 18 15:17:50 <Tantek>	compat with xsd:dateTime
Aug 18 15:17:57 <Tantek>	it's a strict intersection subset
Aug 18 15:17:59 <DanC>	I consider W3C-NOTE-DATETIME obsoleted by XML Schema datatype-- yeah.. xsd:dateTime
Aug 18 15:18:32 <Tantek>	compare/contrast normatively using xsd:dateTime vs. RFC3339
Aug 18 15:18:41 <Tantek>	note: Atom 1.0 chose RFC3339
Aug 18 15:18:50 <Tantek>	i would like input from the microformats community on this
Aug 18 15:19:27 <DanC>	in what context are you evaluating RFC 3339?
Aug 18 15:19:28 <jcgregorio>	http://bitworking.org/news/Date_Constructs_in_the_Atom_Syndication_Format
Aug 18 15:21:24 <DanC>	which microformat is the question coming from, Tantek ?
Aug 18 15:23:31 <DanC>	"   The grammar element time-second may have the value "60" at the end of
Aug 18 15:23:31 <DanC>	   months in which a leap second occurs" The XML Schema WG is in the 27th level of leap-second-hell for the past few months, I gather.
Aug 18 15:24:21 <DanC>	yeah... here's the scary bit: "   Leap seconds cannot be predicted far into the future.  The
Aug 18 15:24:21 <DanC>	   International Earth Rotation Service publishes bulletins [IERS] that
Aug 18 15:24:21 <DanC>	   announce leap seconds with a few weeks' warning."
Aug 18 15:26:03 <Tantek>	DanC, which microformats? any/all that use datetime fields.
Aug 18 15:26:36 <DanC>	hard to give useful advice, then.
Aug 18 15:26:58 <DanC>	I expect they'll use datetime fields for different things that have different cost/benefit trade-offs
Aug 18 15:27:26 <DanC>	do you know of any particular differences that matter to anybody?
Aug 18 15:56:43 <KragenSitaker>	RFC3339 suggests -07:00, which seems like an improvement over -0700 anyway
Aug 18 15:56:49 <Tantek>	Kragen, agreed
Aug 18 15:57:01 <Tantek>	RFC3339 is certainly preferable to the ISO8601 subset in iCalendar
Aug 18 16:05:57 <DanC>	Tantek's right, Kragen; iCalendar looks like it solves the local timezone problem but doesn't.
Aug 18 16:06:14 <DanC>	and it's true that there's no standard solution to the local timezone problem
Aug 18 16:06:39 <Tantek>	so instead of appearing to solve the problem but not solving it, we chose to provide the ability to *approximate* the local timezone using e.g. "-07:00"
Aug 18 16:06:49 <DanC>	the simplest thing is to have people use Z time in hCalendar. But I gather that's unacceptably unusable?
Aug 18 16:07:35 <Tantek>	DanC, yes, the simplest thing is to have everyone use UTC Z
Aug 18 16:07:38 <Tantek>	However
Aug 18 16:07:50 <Tantek>	it is not *nearly* as usuable/verifiable
Aug 18 16:07:55 <Tantek>	as -07:00 etc.
Aug 18 16:08:02 <Tantek>	hence the decision to go with the latter
Aug 18 16:08:12 <Tantek>	some degree of human verifiability is important here
Aug 18 16:14:21 <Tantek>	DanC, my perception is that RFC3339 is a subset
Aug 18 16:17:00 <DanC>	   time-numoffset  = ("+" / "-") time-hour ":" time-minute
Aug 18 16:17:34 <DanC>	ok, then I can't see any differences. (modulo recent leap seconds issues that may affect xsd:dateTime )
Aug 18 16:18:07 <Tantek>	would be interesting to know why Atom 1.0 chose RFC3339 over xsd:dateTime
Aug 18 16:18:21 <Tantek>	if there was a "real" reason or if it was arbitrary / coin-flip.
Aug 18 16:18:43 <KragenSitaker>	rfc3339 is pretty short.
Aug 18 16:19:36 <Tantek>	DanC, BTW, which came first? REC for xsd:dateTime or RFC3339?
Aug 18 16:19:50 <DanC>	RFC3339 is dated July 2002 ...
Aug 18 16:19:54 <KragenSitaker>	Right --- and you might be able to understand xsd:dateTime without reading all of xml schema, you wouldn't be confident of it
Aug 18 16:20:25 <DanC>	W3C Recommendation 28 October 2004 ... but that's 2nd ed...
Aug 18 16:20:47 <DanC>	W3C Recommendation 02 May 2001
Aug 18 16:22:10 <DanC>	I don't see a BNF in http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ...
Aug 18 16:22:43 <KragenSitaker>	yeah, appendix D of the current xml schema datatypes document seems a little scanty, actually
Aug 18 16:23:28 <DanC>	ah... 2nd ed of http://www.w3.org/TR/xmlschema-2/#date is much more explicit about syntax.
Aug 18 16:23:30 <KragenSitaker>	it's 1100 words but still doesn't give any examples
Aug 18 16:23:35 <DanC>	still, it's given in prose and not BNF
Aug 18 16:24:17 <KragenSitaker>	sections 3.2.9 through 3.2.14 seem to be the relevant ones around #date
Aug 18 16:24:29 <KragenSitaker>	which is another 2200 words
Aug 18 16:24:42 <DanC>	wow... they changed the canonical form of date from always-Z to timezone-allowed between 1st edition and 2nd edition
Aug 18 16:25:01 <Tantek>	Kragen, DanC, these are very good analyses
Aug 18 16:25:21 <Tantek>	could I ask you to summarize the pros/cons for each in a new section at end of http://microformats.org/wiki/datetime-design-pattern
Aug 18 16:25:22 <Tantek>	?
Aug 18 16:25:58 <KragenSitaker>	rfc 3339 is 4000 words, excluding the last two pages of boilerplate.
Aug 18 16:26:31 <KragenSitaker>	so it's actually longer than the datetime-relevant parts of XSD but it seems much more rigorous and clear
Aug 18 16:28:37 <DanC>	my advice is: normatively cite both, and claim they specify the same syntax, and let anybody who discovers otherwise send you a bug report with a test case
Aug 18 16:29:12 <KragenSitaker>	danc: nice hack
Retrieved from "http://microformats.org/wiki/index.php?title=datetime-design-pattern&oldid=1385"