Datetime Design Pattern

(Difference between revisions)

Jump to: navigation, search
(added "Individual markup of each date/time component" alternative)
Current revision (19:33, 7 November 2013) (view source)
(be more explicit about abbr datetime-design-pattern being dropped)
 
(33 intermediate revisions not shown.)
Line 1: Line 1:
-
<h1> Datetime Design Pattern </h1>
+
<entry-title> Datetime Design Pattern </entry-title>
-
This is a page for exploring a datetime design pattern.
+
Use the [[HTML5]] time element for all use-cases that the Datetime Design Pattern was created for, thus use &lt;time&gt; instead of &lt;abbr&gt;, e.g.
 +
<source lang=xml>
 +
<time datetime="2012-08-26 20:09-0700">
 +
  8:09pm on August 26th, 2012
 +
</time>
 +
</source>
 +
<div class="usermessage">
 +
If you cannot use the <code>&lt;time&gt;</code> element (e.g. if you're stuck with an old XHTML1 CMS), use the [[value-class-pattern#Date_and_time_values|value class pattern for dates and times]].
-
{{TOC-right}}
+
The abbr use for datetimes in particular has been dropped due to [[#accessibility_issues | accessibility issues]].
 +
</div>
 +
 
 +
= Historical Archive =
 +
The remainder of this page is kept as a historical archive.
 +
 
 +
The abbr datetime-design-pattern has been dropped.
== Purpose ==
== Purpose ==
-
* Use the [[datetime-design-pattern]] to make datetimes that are human readable also formally machine readable.
+
* Use the [[value-class-pattern]] for datetimes for better accessibility.
 +
* Deprecated: The [[datetime-design-pattern]] was used to make datetimes that are human readable also formally machine readable.
== Practical Need ==
== Practical Need ==
-
* This design pattern arose as a result of solving the practical need for human readable dates for [[hcalendar|hCalendar]].
+
* This design pattern arose as a result of solving the practical need for human readable dates and times for [[hcalendar|hCalendar]].
== How to use it ==
== How to use it ==
Line 15: Line 29:
* add a <code>title</code> attribute to the <code>abbr</code> element with the machine readable [[iso-8601|ISO8601]] datetime or date as the value
* add a <code>title</code> attribute to the <code>abbr</code> element with the machine readable [[iso-8601|ISO8601]] datetime or date as the value
-
==Current uses==
+
For ISO8601 datetimes, use the [[value-class-pattern]] instead for better accessibility.
 +
==Current uses==
The pattern, which is now available as part of [[hAtom]], [[hcalendar|hCalendar]], [[hcard|hCard]] and [[hreview|hReview]], is:
The pattern, which is now available as part of [[hAtom]], [[hcalendar|hCalendar]], [[hcard|hCard]] and [[hreview|hReview]], is:
:<pre>&lt;abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ"&gt;Date Time&lt;/abbr&gt;</pre>
:<pre>&lt;abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ"&gt;Date Time&lt;/abbr&gt;</pre>
-
where foo is the semantic classname which is being applied to this date/time, the title of the &lt;abbr&gt; is an ISO 8601 date/time, with an appropriate level of specificity, and "Date Time" is a human-friendly representation of the same date/time.
+
where "foo" is the semantic classname which is being applied to this date/time, the title of the &lt;abbr&gt; is an ISO 8601 date/time, with an appropriate level of specificity, and "Date Time" is a human-friendly representation of the same date/time.
An alternative, if you are using UTC-based timestamps, would be:
An alternative, if you are using UTC-based timestamps, would be:
Line 29: Line 44:
with a single "Z" as per [[iso-8601|ISO 8601]]
with a single "Z" as per [[iso-8601|ISO 8601]]
 +
<strong>Note:</strong> title strings of the form "YYYY-MM-DDTHH:MM:SSZ" may be challenging for humans to read and or understand, thus, use the [[value-class-pattern]] for datetimes.
 +
 +
=== Ruby ===
Ruby: An easy way to get this format from a DateTime is this:
Ruby: An easy way to get this format from a DateTime is this:
:<pre>DateTime.now.to_s</pre>
:<pre>DateTime.now.to_s</pre>
-
== Profile of ISO8601 ==
+
Or alternately, if you're working with Time objects:
 +
<pre>require 'time'
 +
Time.now.iso8601</pre>
 +
== Profile of ISO8601 ==
Any [[microformat]] using the date-time-design pattern {{should}} use a profile of [[iso-8601|ISO8601]]. There are currently two widely used profiles which {{should}} be reused.
Any [[microformat]] using the date-time-design pattern {{should}} use a profile of [[iso-8601|ISO8601]]. There are currently two widely used profiles which {{should}} be reused.
Line 39: Line 60:
* [http://www.w3.org/TR/NOTE-datetime W3C Note on Datetimes]
* [http://www.w3.org/TR/NOTE-datetime W3C Note on Datetimes]
-
==Accessibility issues==
+
== accessibility issues==
 +
Note: Some [[accessibility-issues]] have been raised with Datetime Design Pattern, that have been addressed with the completion of the [[value-class-pattern]].
-
Note: Some accessibility issues have been raised([http://www.webstandards.org/2007/04/27/haccessibility/]) with Datetime Design Pattern, and concerns that its use could breach WCAG accessibility guidelines, that are being addressed as part of the [[abbr-design-pattern-issues]] discussion. Possible change recommendations may follow after the accessibility testing is complete. The accessibility concerns are considerably lessened, even eliminated when using the [[date-design-pattern]], a subset of the [[datetime-design-pattern]].
+
Note also that the accessibility concerns are considerably lessened, even eliminated when using the [[date-design-pattern]], a subset of the [[datetime-design-pattern]].
== Discussion ==
== Discussion ==
 +
<strong>This section need significant gardening, and perhaps archiving of discussions which are primarily historic, as the [[value-class-pattern]] serves to solve much of the issues raised here. [[User:Tantek|Tantek]] </strong>
 +
 +
----
 +
 +
What is the relationship of this pattern to the new <nowiki><time></nowiki> element?  Should this pattern specify additionally that IF the element is a time element AND the element has a "datetime" attribute that the value should be taken from that attribute, otherwise fall back to value-class-pattern, otherwise fall further back to abbr-design-pattern? [[User:Singpolyma|Singpolyma]] 15:22, 5 February 2010 (UTC)
 +
 +
----
 +
This pattern is likely to be highly resuable.
This pattern is likely to be highly resuable.
Line 192: Line 222:
== Other Proposals ==
== Other Proposals ==
 +
'''This section needs a lot of clean-up. Proposals that have been relatively rejected need to be move to another section (or perhaps page), along with succinct summaries as to why they are untenable/infeasible/undesirable.
-
=== strtime instructions as class names ===
+
Remaining proposals probably need to be moved to proper brainstorming pages where they can be considered in a broader context.
 +
Links to all proposals (whether relatively rejected or tentatively being considered) should be kept in this page for comparison purposes for this use case.
 +
 +
[[User:Tantek|Tantek]] 04:50, 4 Sep 2008 (PDT)'''
 +
 +
=== strtime instructions as class names ===
Proposal by DavidLaban (alsuren on freenode) on 8 Jun 2008
Proposal by DavidLaban (alsuren on freenode) on 8 Jun 2008
It might be possible to have a slightly more readable/extensible/elegant format:
It might be possible to have a slightly more readable/extensible/elegant format:
Line 244: Line 280:
Pros:
Pros:
* Allows data to be represented in a "non-harmful" way. Will not be read aloud by screenreaders or seen as tooltips.
* Allows data to be represented in a "non-harmful" way. Will not be read aloud by screenreaders or seen as tooltips.
-
* Minimises mark-up used.
+
* Minimizes mark-up used.
* Arguably more semantic than use of "title" attribute for non-human data.
* Arguably more semantic than use of "title" attribute for non-human data.
Line 270: Line 306:
*** See above cons. Already discussed/rejected many times in the history of microformats discussions. In short, quit wasting time on old ground. Abuses class attribute, or if you prefer, introduces a *new* use of the class attribute, unlike microformats to-date which have simply made use of a well established semantic of the class attribute.  And worst of all, completely violates the visible data [[principle]]. Rejectable on that alone.
*** See above cons. Already discussed/rejected many times in the history of microformats discussions. In short, quit wasting time on old ground. Abuses class attribute, or if you prefer, introduces a *new* use of the class attribute, unlike microformats to-date which have simply made use of a well established semantic of the class attribute.  And worst of all, completely violates the visible data [[principle]]. Rejectable on that alone.
**** The fact that something has been discussed and rejected before is not sufficient grounds for dismissing it out of hand once additional research and thinking has taken place. The &lt;abbr> datetime pattern arguably abused the title attribute and introduced a new use of the title attribute. In the example given (<code><nowiki><span class="dtstart data-20051010T10:10:10-0100">10 o'clock on the 10th</span></nowiki></code>), the data is presented as "10 o'clock on the 10th" - very visible. Yes, of course, it's possible to abuse this proposed pattern, and hide the data, but the same can be said of the abbr pattern or even the class pattern given CSS's display:none property. Experience shows that in most cases, people ''won't'' abuse the pattern to hide data, as they actually ''want'' to show the data on their pages. [[User:TobyInk|TobyInk]] 13:52, 24 Jun 2008 (PDT)
**** The fact that something has been discussed and rejected before is not sufficient grounds for dismissing it out of hand once additional research and thinking has taken place. The &lt;abbr> datetime pattern arguably abused the title attribute and introduced a new use of the title attribute. In the example given (<code><nowiki><span class="dtstart data-20051010T10:10:10-0100">10 o'clock on the 10th</span></nowiki></code>), the data is presented as "10 o'clock on the 10th" - very visible. Yes, of course, it's possible to abuse this proposed pattern, and hide the data, but the same can be said of the abbr pattern or even the class pattern given CSS's display:none property. Experience shows that in most cases, people ''won't'' abuse the pattern to hide data, as they actually ''want'' to show the data on their pages. [[User:TobyInk|TobyInk]] 13:52, 24 Jun 2008 (PDT)
 +
***** There has been no new "additional research and thinking" shown yet for data in the class attribute since it was originally proposed years ago, thus, it should be dismissed until that burden of reintroduction is met. [[User:Tantek|Tantek]] 22:05, 24 February 2009 (UTC)
**** It's not an abuse of the class attribute according to the HTML spec. as I read it. Whereas using title for non-human data is (the spec says audio agents may read it aloud, for example). If it's a new use, it's one the writers of HTML4 considered, so it wasn't new to them. [[User:Dracos|Dracos]] 03:38, 25 Jun 2008 (PDT)
**** It's not an abuse of the class attribute according to the HTML spec. as I read it. Whereas using title for non-human data is (the spec says audio agents may read it aloud, for example). If it's a new use, it's one the writers of HTML4 considered, so it wasn't new to them. [[User:Dracos|Dracos]] 03:38, 25 Jun 2008 (PDT)
-
** Relevant princeples are 'humans first, machines second', and 'visible data is ''better'''.  These are ''preferences'', not inviolable principles.  Besides, the existing datetime spec doesn't adhere to these principles anyway: prioritising humans first, <code><nowiki>let's discuss this at the next meeting</nowiki></code> should be marked up as <code><nowiki>let's discuss this at the <abbr title="28th June 2008 at 3:15pm">next meeting</nowiki></code>.  There's a conflict between human- and machine-readable dates.  It makes more sense to 'hide' the machine-readable data in the only attribute available to us: <code>class</code>.  --[[User:AshSearle|AshSearle]] 03:02, 25 Jun 2008 (PDT)
+
** Relevant principles are 'humans first, machines second', and 'visible data is ''better'''.  These are ''preferences'', not inviolable principles.  Besides, the existing datetime spec doesn't adhere to these principles anyway: prioritising humans first, <code><nowiki>let's discuss this at the next meeting</nowiki></code> should be marked up as <code><nowiki>let's discuss this at the <abbr title="28th June 2008 at 3:15pm">next meeting</nowiki></code>.  There's a conflict between human- and machine-readable dates.  It makes more sense to 'hide' the machine-readable data in the only attribute available to us: <code>class</code>.  --[[User:AshSearle|AshSearle]] 03:02, 25 Jun 2008 (PDT)
*** Indeed - by their nature, ''principles'' are ''generalisations'', and while broadly useful, usually have exceptions. After experience, the microformats community is beginning to see some of these. Human vs machine dates is the one gathering the most interest at the moment, largely thanks to <abbr class="help" style="border-bottom:1px dotted" title="the Web Standards Project">WaSP</abbr> and <span class="help" style="border-bottom:1px dotted" title="the BBC">auntie</span>, but I think other properties which will probably emerge as exceptions to the general microformats principles are hReview's <code>type</code> property, and the its namesake subproperty for hCard's <code>tel</code>, <code>email</code> and <code>adr</code> (and <code>label</code>?) properties. [[User:TobyInk|TobyInk]] 12:51, 25 Jun 2008 (PDT)
*** Indeed - by their nature, ''principles'' are ''generalisations'', and while broadly useful, usually have exceptions. After experience, the microformats community is beginning to see some of these. Human vs machine dates is the one gathering the most interest at the moment, largely thanks to <abbr class="help" style="border-bottom:1px dotted" title="the Web Standards Project">WaSP</abbr> and <span class="help" style="border-bottom:1px dotted" title="the BBC">auntie</span>, but I think other properties which will probably emerge as exceptions to the general microformats principles are hReview's <code>type</code> property, and the its namesake subproperty for hCard's <code>tel</code>, <code>email</code> and <code>adr</code> (and <code>label</code>?) properties. [[User:TobyInk|TobyInk]] 12:51, 25 Jun 2008 (PDT)
 +
**** Unless you can provide better principles, it is not reasonable to violate the principles. When principles are in conflict, then one must make reasoned cases for the various possibilities (that uphold one principle but perhaps violate another). [[User:Tantek|Tantek]] 22:05, 24 February 2009 (UTC)
==== Experimental Parser Support ====
==== Experimental Parser Support ====
Line 292: Line 330:
=== date and time separation using value excerption ===
=== date and time separation using value excerption ===
-
 
+
Moved to [[value-excerption-pattern-brainstorming#date_and_time_separation|value excerption pattern brainstorming]] which is a better way of thinking about this.
-
==== summary ====
+
-
By specifying a more precise parsing of the use of "value" excerption inside all datetime properties (e.g. dtstart, dtend, published, updated etc.), dates and times can be marked up separately, thus reducing/minimizing (and potentially eliminating) the readability issues that come with compound ISO8601 datetimes.
+
-
 
+
-
==== introductory example ====
+
-
The sentence:
+
-
 
+
-
<pre><nowiki>
+
-
The weekly dinner is tonight at 6:30pm.
+
-
</nowiki></pre>
+
-
 
+
-
would be marked up as:
+
-
+
-
<pre><nowiki>
+
-
The weekly dinner is <span class="dtstart"><abbr class="value" title="2008-06-24">tonight</abbr>
+
-
at <abbr class="value" title="18:30">6:30pm</abbr></span>.
+
-
</nowiki></pre>
+
-
 
+
-
==== advantages ====
+
-
* re-uses the readable [[abbr-date-pattern]]
+
-
* identifies a similarly readable abbr-time-pattern.
+
-
* minimizes DRY violation distance, keeps machine data on exactly the same element as the respective human data
+
-
** even better than [[abbr-datetime-pattern]] does, which, in practice from experience often required specifying the date in machine readable form on the human readable time (separate from the human readable date).
+
-
* introduces no new class names - [[principle]] of minimal invention
+
-
* introduces no new use of the class attribute - principle of minimal invention again
+
-
* introduces no new syntax ([[datetime-design-pattern#problems_with_strtime_proposal|see above]] about any publishing method that requires the author to think like a programmer being a non-starter, and introducing new syntax almost always requires authors to think like programmers).
+
-
* and most importantly, introduces no dark data.
+
-
 
+
-
==== issues ====
+
-
Some potential issues were raised in IRC, and it helps to document/resolve them so that they are not brought up repeatedly.
+
-
* [[http://rbach.priv.at/Microformats/IRC/2008-06-24#T163114 Does this sufficiently address the concerns raised with the current use of abbr-pattern?]]
+
-
*# The [[abbr-date-pattern]], as documented and explained by [[User:Adactio|Jeremy Keith]] is just fine (in contrast to the [[abbr-datetime-pattern]]).
+
-
*# Similar to the [[abbr-date-pattern]], this proposal implies/introduces the abbr-time-pattern, which is similarly acceptable.
+
-
*# In addition, as long there is incremental improvement, we are making progress. It is more important to take small steps that we know will help some things, rather than try to take a big step that is more risky in the attempt to help more but may not actually do so (as most big changes don't), therefore "sufficiently" is a flawed way of evaluating incremental fixes.
+
-
* Exposes data through tooltips. Separating into 2008-06-07 and 18:03 improves the ability for humans to consume the data, but still exposes data through tooltips and speech in formats that the publisher did not choose to use. --[[User:BenWard|BenWard]] 04:52, 25 Jun 2008 (PDT)
+
-
*# This is a feature, not a bug. By making the duplicated data at least *somewhat* visible (rather than fully invisible), effective data quality is increased due to the fact that the probability of the ISO8601 and locale-specific data getting out-of-sync is reduced because of the increased visibility (and therefore the increased inspectability and more eye-balls looking at/for problems effect).
+
-
*# Workaround: if a site publisher wishes to customize the presentation of tooltips, they can do so with a nested span with title.
+
-
*#* That proposes extraneous mark-up maintain some publisher's wish not to have a tool-tip in the first place. I object to a microformat pattern requiring an immediate work-around to meet publisher's desires. It goes against ‘Humans first…’. --[[User:BenWard|BenWard]] 09:09, 30 Jun 2008 (PDT)
+
-
*#*# Additional markup has nothing to do with "Humans first".
+
-
*#*# Additional markup to work-around minor issues (e.g. CSS, cross-browser compatibility, etc.) is a well accepted modern web design practice.  It's not ideal, but it is both accepted and widely practiced. With the use of <code>&lt;span&gt;</code> and <code>&lt;div&gt;</code> elements, it's also semantically neutral, therefore not a problem from that perspective either.
+
-
*#*# Finally, it should not be our goal to try to satisfy *every* publisher, for that would make every microformat beholden to every publisher and contort the design of microformats in really poor ways.  We must accept that not all publishers will adopt all microformats and that is ok. Our goal to incrementally increase the number of publishers that adopt microformats, not to try to satisfy each and every one.
+
-
* Semantic misuses of ABBR. That ‘tonight’ is ever a textual, human abbreviation of ‘2008-06-24’ is not accepted.
+
-
*# Semantic stretch not misuse. It is a semantic abbreviation rather than a purely syntactical (character shortening) abbreviation, but it is an abbreviation in context nonetheless. Though this may stretch what may be commonly expected as an "abbreviation", the HTML4 spec does seem to allow some flexibility here ([http://www.w3.org/TR/html401/struct/text.html#h-9.2.1 HTML 4.01 9.2.1 Phrase elements]).
+
-
* Maintaining proper sentences with the expanded form. It is not always possible to use this mark-up and maintain proper sentences with the expanded form. e.g. <code>it's my &lt;abbr class="bday" title="2005-06-20">birthday today&lt;/abbr>!</code> becomes ‘it's my 2005-06-20!’.  And thus audio rendition of such titles can be nonsensical - "The weekly dinner is two thousand and eight dash zero six dash twenty four at eighteen thirty."
+
-
*# This can and should be addressed by improving authoring examples so that practices improve with experience.
+
-
* Publishing practices and desires show us that authors are not willing to compromise the semantics of abbr. [[User:Phae|Phae]] 04:30, 27 Jun 2008 (PDT)
+
-
*# Without specific citations of which authors and what specific issues they have, we are unable to address their issues.
+
-
*# See also above - not our goal to satisfy *every* publisher, but rather to incrementally satisfy more and more.  We must accept that  there may be some authors we are unable to satisfy in the immediate/short-term.
+
-
* [[http://rbach.priv.at/Microformats/IRC/2008-06-24#T163435 That's getting pretty complicated]]
+
-
** Much less complicated than inventing yet another syntax ( " { ... } " ???? ) that web authors would have to learn.
+
-
*** But it's all in one place, rather than spreading it out.
+
-
**** The spreading it out is what current content publishing practices do already! It is much more important to map the machine data as close to the existing publishing practice as possible, than to try to "put it all in one place".  The "put it all in one place" way of thinking is why people ended up sticking so much invisible metadata in the head of the document, which we know fails.
+
-
 
+
-
==== content requirements ====
+
-
Some requirements which enhance both human readability, ''and'' machine parsability (best of both) :
+
-
* date value excerpts MUST use hyphen separators. E.g. 2008-06-24.  Not ok:20080624.
+
-
* time value excerpts MUST use colon separators (seconds optional, implied :00 if absent). E.g. 18:30 or 18:30:00.  Not ok:183000.
+
-
* timezone value excerpts MUST use leading plus or minus and NO colon separator. E.g. -0700.  Not ok:-07:00.
+
-
 
+
-
==== derivation ====
+
-
It's important to document the derivation/background of a brainstorm/proposal as it allows others to see some of the thinking that went into it, and avoid having to rediscuss alternatives already considered, and helps provide understanding as to why aspects of the design are as they are.
+
-
===== example with datetime =====
+
-
Here is a short code example:
+
-
<pre><nowiki>
+
-
the weekly dinner is tonight at <span class="dtstart">2008-06-24T18:30</span>
+
-
</nowiki></pre>
+
-
===== example with abbr datetime =====
+
-
However that's not the easiest to read, nor do most people publish that as human visible text, so per the abbr-datetime pattern:
+
-
<pre><nowiki>
+
-
the weekly dinner is tonight at <abbr class="dtstart" title="2008-06-24T18:30">6:30pm</abbr>
+
-
</nowiki></pre>
+
-
 
+
-
which has raised two issues:
+
-
# When "2008-06-24T18:30" is inspected by a human reading a tooltip, or spoken by a screen reader, it's not the most understandable thing (precise citation needed, perhaps an mp3 with screen reader used version info).
+
-
# There is a non-local violation of DRY (which IMHO is a worse problem, as it leads to worse data quality -[[User:Tantek|Tantek]]). That is, the "date" information is now not only in the text twice (as it was before), but those two instances of the date information are not on the same element, which makes it worse. That is, "tonight" is in the prose, ''outside'' of the element with the precise date "2008-06-24".
+
-
 
+
-
In analysis of examples of event information on the web, the date and time are often published in separate elements, often for display purposes.
+
-
 
+
-
Thus it is this existing content publishing practice which leads to this brainstorm proposal, to essentially to introduce a date and time value excerption longhand.
+
-
 
+
-
(Initially [http://rbach.priv.at/Microformats/IRC/2008-06-21#T181634 Tantek's idea that he bounced off Jeremy Keith]  ([http://rbach.priv.at/Microformats/IRC/2008-06-24#T124652 similar idea conceived by Drew independently]) was to  [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161819 introduce new classes "datevalue", "timevalue"] and "tzvalue" for this purpose, but [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171603 Bob Jonkman pointed out] that HTML5's time parsing algorithm enables a single <nowiki><time></nowiki> element to contain dates or times (with or without timezone) without having to explicitly say whether the value contains dates or times (with or without timezone). [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171723 Bob then proposed] that thus all was needed was a single new "datetime" class name.  This was the key realization that allowed minimal invention. Tantek pointed out that since from the type of property we already know it is a datetime, [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171835 there was no need for even one new class name], that we could simply re-use "value" excerption, and simply more precisely specify the semantics/parsing in the case of datetime properties.)
+
-
 
+
-
===== example with new date and time value excerpts =====
+
-
Thus we markup the date and time separately, as value excerpts, using the [[abbr-date-pattern]] and an implied parallel abbr-time-pattern:
+
-
 
+
-
<pre><nowiki>
+
-
The weekly dinner is <span class="dtstart"><abbr class="value" title="2008-06-24">tonight</abbr>
+
-
at <abbr class="value" title="18:30">6:30pm</abbr></span>.
+
-
</nowiki></pre>
+
-
 
+
-
===== separate subtrees =====
+
-
The proposal also allows setting the date and time in separate element subtrees as well, which may be necessary for some document structures:
+
-
 
+
-
<pre><nowiki>
+
-
the weekly dinner is <span class="dtstart"><abbr class="value" title="2008-06-24">tonight</abbr></span>
+
-
at <span class="dtstart"><abbr class="value" title="18:30">6:30pm</abbr></span>.
+
-
</nowiki></pre>
+
-
 
+
-
Note the two instances of dtstart, one of which sets the date for the dtstart, and the other of which sets the time.
+
-
 
+
-
The idea being, when a parser sees a datetime property (e.g. dtstart) with a value excerpt, that it only "set" the component of its full value that is specified by the value excerpt (e.g. the date), and that if lacking a complete datetime, it continue to parse additional instances of that datetime property for the remaining component(s) (e.g. the time).
+
-
 
+
-
Of course this only works for singular properties, but fortunately all instances of datetime properties so far are singular, so this works.
+
-
* hCard's <code>rev</code> is plural. [[User:TobyInk|TobyInk]]
+
-
** can someone give a reference to this being the case? The RFC says "The value distinguishes the current revision of the information in this vCard for other renditions of the information." Does it make sense to have multiple REV dates in a single vCard?
+
-
*** The RFC is ambiguous as usual, but a contact card could conceivably have had several changes made to it, with a <code>rev</code> for each. ("Change logs" are fairly common on the web.) The [[hcard|hCard spec]] is fairly specific about which properties are [[hcard#Singular_vs._Plural_Properties|singular]] and which are not, and <code>rev</code> is not included in the list of singular properties.
+
-
 
+
-
===== reusing date data for multiple datetime properties =====
+
-
This also provides a *very* convenient way to re-use the same date information for start and end, e.g. expanding the example:
+
-
 
+
-
<pre><nowiki>
+
-
the weekly dinner is <span class="dtstart dtend"><abbr class="value" title="2008-06-24">tonight</abbr></span>
+
-
from <span class="dtstart"><abbr class="value" title="18:30">6:30</abbr></span> -
+
-
<span class="dtend"><abbr class="value" title="20:30">8:30pm</abbr></span>.
+
-
</nowiki></pre>
+
-
 
+
-
Note what just happened. we just eliminated another duplication of date information by reusing the start *date* information for the end *date* information and *only* specifying the end *time* information separately for the two properties.
+
-
 
+
-
Reducing the duplication (or triplication) of such data helps to reduce the chances of (even inadvertent) data corruption/drift/divergence among any duplicates.
+
-
 
+
-
===== time zones =====
+
-
There are a few choices for timezones.
+
-
# Simply include the time zone information as part of the time "value". <br /> E.g. <code><nowiki><abbr class="value" title="18:30-0700">6:30pm</abbr></nowiki></code>
+
-
# Or use another value excerpt for the timezone (was: <del>introduce the class name "tzvalue"</del>) <br /> E.g. <code><nowiki><abbr class="value" title="18:30">6:30pm</abbr> <abbr class="value" title="-0700">PDT</abbr></nowiki></code>
+
-
# Or allow both and let web authors decide. This is the current leaning.
+
-
#* if web authors want to specify timezone as part of the time (first example above), they can,
+
-
#* or if web authors visibly publish the timezone separately (second example above), then they can mark that up.
+
-
#* or if web authors wish to omit timezone information, they can do so as well, as most do today. In practice this works fine, as it creates a "floating" time which works fine in far more than the 80/20.
+
-
 
+
-
 
+
-
 
+
-
(more to come, documenting [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 from IRC logs])
+
-
 
+
-
==== discussion ====
+
-
Opening up a discussion section even though documentation [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 from IRC logs] is still in progress. :)
+
-
 
+
-
* regarding the [[datetime-design-pattern#advantages|advantage]] of "and most importantly, introduces no dark data."
+
-
** "Dark data" is sometimes what publishers *want* to publish. To use the example of TV schedules which kick started the renewed discussion in this area, publishers will often not want to display the date. For instance, if a page entitled "Tomorrow's TV" and containing 300 different programmes marked up with <code>dtstart</code>, it is superfluous to explicitly display the date for each one. With this proposed solution the [[include|include pattern]] could be used to include the date into each vevent, but a visible link to the date on each programme would simply be confusing. Sometimes it just makes sense to hide some of the information you're publishing as a microformat - because the information you want to make explicit to parsers can be inferred from context by humans, or is more appropriately displayed at a different level of granularity for machines and humans. [[User:TobyInk|TobyInk]] 14:26, 24 Jun 2008 (PDT)
+
-
*** It doesn't matter whether publishers *want* to publish dark data or not. Invisible data always leads to poorer quality data. Publishers publish all kinds of invisible metadata in the heads of documents etc. because they want to, but their desire doesn't stop the data from becoming obsolete, diverging from the actual visible data etc.  The quality of the data matters more than any publishers wish(es) of publishing in a specific format, or in a hidden way.  In the example you gave, using the include pattern in that way would not result in any visible links, but merely empty include anchors.  It never makes any sense to actually hide "some of the information you're publishing as a microformat", because historically that always results in some loss of data quality over time and thus the microformats [[principle]] of visible data instead of invisible metadata. [[User:Tantek|Tantek]] 14:32, 24 Jun 2008 (PDT)
+
-
**** All microformats hide ''some'' data. In the example <code><nowiki><span class="tel">01632 960123</span></nowiki></code>, the information that the long string of numbers represents a telephone number is invisible. And making it visible (<code><nowiki>Tel: <span class="tel">01632 960123</span></nowiki></code>) violates DRY. It's just a matter of where to draw the line.
+
-
***** That statement makes the mistake of conflating *type* data and *content* data.  "tel" is not content data, just as <nowiki><p></nowiki> is not content data. It's markup, indicating the type of the data. Markup (type data) being invisible to the user has worked just fine.  Content (content data) being invisible to the user is the problem of dark data. Or rather, if you think that everything is data, then you really should be spending time developing in a system that is built on that assumption, e.g. RDF, rather than microformats, which are built on HTML, and the clear separation of type of data (HTML elements, microformats properties) and content data (inner text, text attribute values).
+
-
****** My point is that there isn't a ''distinction'' between the two, but a ''continuum''. The choice of where to draw the line is never a clear one and always somewhat arbitrary. The vCard standard could quite easily have ended up with separate "TEL", "FAX" and "CELL" properties, in which case hCard would have ended up with <code><nowiki><foo class="tel"></nowiki></code>, <code><nowiki><bar class="fax"></nowiki></code> and <code><nowiki><baz class="cell"></nowiki></code>. Going the other way, they could have stored e-mail addresses as mailto: URLs, and then hCard would have <code><nowiki><a class="url" href="mailto:quux@example.com"></nowiki></code>. They chose the way they did, and as a result in hCard the distinction between a mailto: URI and an http: URI is largely invisible (in most circumstances only obvious by looking at the status bar when hovering), but the distinction between a telephone number and a fax number is visible. But that wasn't the only possible (nor the only reasonable) outcome.
+
=== HTML 5 <code>&lt;time></code> Element ===
=== HTML 5 <code>&lt;time></code> Element ===
-
 
[http://microformats.org/wiki/hcalendar-issues#html5-time-element See hCalendar issues]
[http://microformats.org/wiki/hcalendar-issues#html5-time-element See hCalendar issues]
=== Plain Old English alternative to ISO date ===
=== Plain Old English alternative to ISO date ===
-
 
Example (in English):
Example (in English):
<pre>
<pre>
-
<abbr title="January 25th, 2008" class="dstart" lang="en-us">1/25</abbr>
+
<abbr title="January 25th, 2008" class="dtstart" lang="en-us">1/25</abbr>
</pre>
</pre>
<pre>
<pre>
-
<span class="dstart">January 25th, 2008</span>
+
<span class="dtstart">January 25th, 2008</span>
</pre>
</pre>
Line 456: Line 351:
<pre>
<pre>
-
<abbr title="25 Janvier 2008" class="dstart" lang="fr">25/1</abbr>
+
<abbr title="25 Janvier 2008" class="dtstart" lang="fr">25/1</abbr>
</pre>
</pre>
Line 469: Line 364:
* DRY compliant if HTML human authors are willing to write in correct English
* DRY compliant if HTML human authors are willing to write in correct English
-
====Discussion====
+
==== Disadvantages ====
 +
Most extracted from discussion below.
 +
* huge requirement of knowledge of locale-specific information in implementations
 +
* very high complexity of implementation , perhaps even impossible, due to the knowledge required
 +
* unreliability in general: "Getting it wrong would be worse than not getting it at all! "
 +
* unreliability in mixed locale content
 +
* unreliable according to implementation experience to date (see discussion below)
 +
* authoring drift, NLP arms race. because proposal looks like natural language, authors will try any natural language format.
 +
* widespread implementer objection to NLP based solutions
 +
====Discussion====
* Locale-specific parsing logic.
* Locale-specific parsing logic.
* Not all cultures use the same calendar — Dan Brickley
* Not all cultures use the same calendar — Dan Brickley
Line 483: Line 387:
====Notes====
====Notes====
-
 
* Could work alongside with the existing [[datetime-design-pattern]]: if ISO date parsing fails, try parsing the title as a human-readable plain old English/French/... date according to the locale.
* Could work alongside with the existing [[datetime-design-pattern]]: if ISO date parsing fails, try parsing the title as a human-readable plain old English/French/... date according to the locale.
===<code>&lt;object></code> element to represent dates===
===<code>&lt;object></code> element to represent dates===
-
 
* Re-raised by George Brocklehurst on June 25th 2008.
* Re-raised by George Brocklehurst on June 25th 2008.
Line 499: Line 401:
** Absolute URIs can't start with a number, but relative ones can - and the data attribute is permitted to contain relative URIs. [Don't need to use data:// URI) — Toby A Inkster
** Absolute URIs can't start with a number, but relative ones can - and the data attribute is permitted to contain relative URIs. [Don't need to use data:// URI) — Toby A Inkster
* Could also look at <code>&lt;object class="dtstart">&lt;param name="value" value="20050125" />January 25&lt;/object></code> — Scott Reynen
* Could also look at <code>&lt;object class="dtstart">&lt;param name="value" value="20050125" />January 25&lt;/object></code> — Scott Reynen
-
* 1. The purpose of the &lt;object> element is to allow the browser to run an external application for a non-native data type (e.g., Java applet). See:  http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3. Object is not the right way to go in this case. — Sarven Capadisli
 
-
==Individual markup of each date/time component==
+
==== issues ====
 +
Open issues related to this proposal. Some may require additional information to be acted upon / resolved.
 +
 
 +
* Not providing OBJECT WIDTH and HEIGHT causes the displaying page to flicker;  --[[User:Yecril71pl|Yecril71pl]] 21:56, 24 February 2009 (UTC)
 +
** Please provide specific implementation (maker, name, version number, platform) that cause the displaying page to flickr.
 +
 
 +
* OBJECT boundaries are impermeable to CSS.  --[[User:Yecril71pl|Yecril71pl]] 21:56, 24 February 2009 (UTC)
 +
** Please provide a URL to an example use of OBJECT that demonstrates problems with applying CSS to the contents of the OBJECT (i.e. beyond its boundaries).
 +
 
 +
 
 +
==== resolved issues ====
 +
Issues raised and resolved related to this proposal. Issues that are misconceptions (e.g. easily refuted by citing the HTML4 specification) are resolved by moving to the separate misconceptions section below with explanation/citation for why they are misconceptions.
 +
 
 +
* The purpose of the &lt;object> element is to allow the browser to run an external application for a non-native data type (e.g., Java applet). See:  http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3. Object is not the right way to go in this case. — Sarven Capadisli
 +
** "datetime" *is* a non-native data type, and its common presentation is essentially a lowest common denominator (what's supported) plain text fallback. Better would be for code to recognize and present date and time information to the user in a format they can understand (perhaps adjusting the presentation for the user's locale settings). Object makes sense semantically for representing date and time information, as it is a semantic for embedding arbitrary data. [[User:Tantek|Tantek]] 21:39, 24 February 2009 (UTC)
 +
** note the mention of "external application" may sometimes cause the misconception (i.e. see below) that object MUST be used to run an external application. This is false. Authors may specify the "classid", which implies an implementation, or they may specify the "type" and "data" attributes which the browser may then display natively or use the "type" attribute to find external code to display the data. [[User:Tantek|Tantek]] 21:39, 24 February 2009 (UTC)
 +
 
 +
* Providing OBJECT WIDTH and HEIGHT will break the typographical consistency of running text.  --[[User:Yecril71pl|Yecril71pl]] 21:56, 24 February 2009 (UTC)
 +
** This is a [http://tr.im/strawman Strawman] issue. This proposal never advocated using WIDTH and HEIGHT.
 +
 
 +
* Specifying a DATA attribute causes an unnecessary round-trip to the server.  And what if it succeeds?  --[[User:Yecril71pl|Yecril71pl]] 21:59, 24 February 2009 (UTC)
 +
** This is a [http://tr.im/strawman Strawman] issue. This proposal lacks any examples which use "http:" in the DATA attribute or any other URI scheme which will cause a round-trip to the server.
 +
 
 +
==== misconceptions ====
 +
===== external application only =====
 +
* ''The purpose of the &lt;object> element is to allow the browser to run an external application...'' — Sarven Capadisli
 +
* ''OBJECT elements are for external content, not for arbitrary data;'''  --[[User:Yecril71pl|Yecril71pl]] 21:56, 24 February 2009 (UTC)
 +
 
 +
This is false. From the [http://www.w3.org/TR/html401/struct/objects.html#h-13.3 HTML4.01 section on OBJECT]:
 +
 
 +
<blockquote><p>Still others [other objects] may not require additional implementation information, i.e., the user agent itself may already know how to render that type of data (e.g., GIF images).</p></blockquote>
 +
 
 +
Thus browsers may render OBJECTs themselves, like images, and external applications are not necessarily required. For example IE5/Mac supported native rendering of PNG images even as objects, while other browsers at the time (2000) which supported OBJECT, only rendered PNG images via external plugins.
 +
 
 +
===== need width and height =====
 +
* ''OBJECT elements need WIDTH and HEIGHT''  --[[User:Yecril71pl|Yecril71pl]] 21:56, 24 February 2009 (UTC)
 +
 
 +
This is false. Per the [http://www.w3.org/TR/html401/struct/objects.html#h-13.3 HTML4.01 section on OBJECT], the width and height attributes are "#IMPLIED" not "#REQUIRED".
 +
 
 +
===Individual markup of each date/time component===
 +
'''A variant of this idea has been documented into a [[value-excerption-pattern-brainstorming#details_for_handling_specific_property_types|specific proposal]] and is [[value-excerption-dt-separation-test|being tested]]. Please see the [[value-excerption-pattern-brainstorming#details_for_handling_specific_property_types|value excerption pattern brainstorming: date and type separation]] and [[value-excerption-dt-separation-test]] page for updated details. [[User:Tantek|Tantek]] 22:05, 24 February 2009 (UTC)'''
A combination of suggestions that originated from this [http://www.mail-archive.com/microformats-discuss@microformats.org/msg10218.html post]
A combination of suggestions that originated from this [http://www.mail-archive.com/microformats-discuss@microformats.org/msg10218.html post]
Line 524: Line 465:
<pre>
<pre>
-
<span class="dstart" lang="en-us"><span class="date"><span class="mo">October</span> <span class="day">5</span>, <span class="yr">2004</span><span> at <span class="time"><span class="hr">6</span><span class="">PM</span></span></span>
+
<span class="dtstart" lang="en-us">
 +
<span class="date">
 +
<span class="mo">October</span> <span class="day">5</span>, <span class="yr">2004</span>
 +
<span> at  
 +
<span class="time">
 +
<span class="hr">6</span><span class="">PM</span>
 +
</span>
 +
</span>
</pre>
</pre>
-
<code>date</code> maybe not required since <code>dstart</code> IS a <code>date</code>.
+
<code>date</code> maybe not required since <code>dtstart</code> IS a <code>date</code>.
For a duration:
For a duration:
<pre>
<pre>
-
<span class="duration time">
+
<span class="duration">
-
     <span class="hr">1</span>:
+
     <span class="h">1</span>:
     <span class="min">3</span>:
     <span class="min">3</span>:
     <span class="s">42</span>
     <span class="s">42</span>
</span>
</span>
</pre>
</pre>
 +
 +
* An example of this is also documented on [[ISO-31-1]]
'''Issues'''
'''Issues'''
* the internationalization issue is not addressed, but it is limited to the month of the year.
* the internationalization issue is not addressed, but it is limited to the month of the year.
 +
* Tonnes and tonnes of nested elements to mark up something that's essentially very simple. Microformats are "for humans first, machines second", but this suggestion appears to be friendly to neither! [[User:TobyInk|TobyInk]] 02:21, 12 Aug 2008 (PDT)
 +
** Also worth pointing out that the complexity issue applies less to durations. With durations, most people will probably only want to use a combination of 1 to 3 time components (e.g. d+h, h+min+s, h+min, min+s, d only, h only, min only, s only) But with datetimes, they're likely to want to specify at least five components (y+m+d+h+min) and often also the timezone (seconds, and fractions thereof, are not especially useful for the majority of use cases). So marking up the time components might be OK for durations, but becomes onerous for datetimes.
== See Also ==
== See Also ==
Line 550: Line 502:
* RFC [http://www.faqs.org/rfcs/rfc3339.html 3339]: Date and Time on the Internet: Timestamps
* RFC [http://www.faqs.org/rfcs/rfc3339.html 3339]: Date and Time on the Internet: Timestamps
* W3C: [http://www.w3.org/TR/NOTE-datetime Note on Datetimes]  
* W3C: [http://www.w3.org/TR/NOTE-datetime Note on Datetimes]  
 +
* W3C: [http://www.w3.org/QA/Tips/iso-date Use international date format (ISO) - Quality Web Tips]
* Markus Kuhn: [http://www.cl.cam.ac.uk/~mgk25/iso-time.html A summary of the international standard date and time notation]
* Markus Kuhn: [http://www.cl.cam.ac.uk/~mgk25/iso-time.html A summary of the international standard date and time notation]
* Wikipedia: [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]
* Wikipedia: [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]

Current revision

Use the HTML5 time element for all use-cases that the Datetime Design Pattern was created for, thus use <time> instead of <abbr>, e.g.

<time datetime="2012-08-26 20:09-0700">
  8:09pm on August 26th, 2012
</time>

If you cannot use the <time> element (e.g. if you're stuck with an old XHTML1 CMS), use the value class pattern for dates and times.

The abbr use for datetimes in particular has been dropped due to accessibility issues.

Contents

Historical Archive

The remainder of this page is kept as a historical archive.

The abbr datetime-design-pattern has been dropped.

Purpose

Practical Need

How to use it

For ISO8601 datetimes, use the value-class-pattern instead for better accessibility.

Current uses

The pattern, which is now available as part of hAtom, hCalendar, hCard and hReview, is:

<abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">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, with an appropriate level of specificity, and "Date Time" is a human-friendly representation of the same date/time.

An alternative, if you are using UTC-based timestamps, would be:

<abbr class="foo" title="YYYY-MM-DDTHH:MM:SSZ">Date Time</abbr>

with a single "Z" as per ISO 8601

Note: title strings of the form "YYYY-MM-DDTHH:MM:SSZ" may be challenging for humans to read and or understand, thus, use the value-class-pattern for datetimes.

Ruby

Ruby: An easy way to get this format from a DateTime is this:

DateTime.now.to_s

Or alternately, if you're working with Time objects:

require 'time'
Time.now.iso8601

Profile of ISO8601

Any microformat using the date-time-design pattern SHOULD use a profile of ISO8601. There are currently two widely used profiles which SHOULD be reused.

accessibility issues

Note: Some accessibility-issues have been raised with Datetime Design Pattern, that have been addressed with the completion of the value-class-pattern.

Note also that the accessibility concerns are considerably lessened, even eliminated when using the date-design-pattern, a subset of the datetime-design-pattern.

Discussion

This section need significant gardening, and perhaps archiving of discussions which are primarily historic, as the value-class-pattern serves to solve much of the issues raised here. Tantek


What is the relationship of this pattern to the new <time> element? Should this pattern specify additionally that IF the element is a time element AND the element has a "datetime" attribute that the value should be taken from that attribute, otherwise fall back to value-class-pattern, otherwise fall further back to abbr-design-pattern? Singpolyma 15:22, 5 February 2010 (UTC)


This pattern is likely to be highly resuable.

--User:RyanKing

Can this not be viewed as a microformat in itself?

--User: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.

Here's an exhaustive comparison from ndw. I think xsd:dateTime also allows unqualified local times, while RFC3339 allows only UTC with no known timezone (-00:00). In the end, Atompub followed the advice of Sam Ruby and Scott Hollenbeck, our area director. Atom dates make some additional restrictions on RFC3339, such as uppercase T and Z characters for compatibility with xsd:dateTime, RFC3339, W3C-DTF, and ISO8601. --Robert Sayre

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


The RFC3339 has a mandatory TIME portion of the DATE-TIME. Some vCard/iCalendar DATE-TIME stamps can omit the TIME. For instance, DTSTART, if that is a full day event, then you can omit the time. BDAY in vCard can be respresented by only a DATE. I like the idea of restricting the possible date formats, but i think that TIME should be optional, which it isn't in RFC3339. - brian suda

RFC 3339 allows lowercase 't' and 'z' while XSD doesn't. Specifying RFC 3339 plus 'T' and 'Z' MUST be caps will make them the same. - Joe Gregorio

---

A few questions: asked by CharlesBelov 16:57, 24 Apr 2007 (PDT), answered by JamesCraig on 15:58, 5 Jul 2007 (PDT).

  1. Would it make more sense for documenting the alternative codings pitting the abbr tag vs. other tags to be on this page? Answer: That documentation should go on the assistive-technology-abbr-results page.
  2. Would using the title attribute of the abbr tag to encode the machine-readable date in fact cause a failure of WCAG 2.0 Accessibility? What about USA Section 508? It does appear to violate Technique for WCAG 2.0 H28: Providing definitions for abbreviations by using the abbr and acronym elements, although that is a supporting document and does not have the force of a guideline. Answer: Yes, it appears that is in violation of WCAG, 508, et al, so alternatives are being discussed on the assistive-technology-abbr-results page.
  3. In order to maintain accessibility, would it make sense to enclose the machine-readable date in a span with a style of "display:none" instead of using the abbr tag? Answer: please refer to and add any suggestions to assistive-technology-abbr-results.
  4. For that matter, wouldn't you want to style such an abbr tag with text-decoration:none to hide that an abbr tag was used? Otherwise, visitors might cursor over the time, see the machine time, and be annoyed that their time was wasted or else be confused. And I don't think you can suppress the title from coming up if the human-readable time was inadvertently hovered. Answer: Microformats should not rely on CSS in order to work properly, but again, that discussion can be found here: assistive-technology-abbr-results.

Code

The following regular expression (parsed VERBOSE) should break apart a datetime and cover many lightly broken cases seen in the wild. This has been tested under Python.

 ^
 (?P<year>\d\d\d\d)
 ([-])?(?P<month>\d\d)
 ([-])?(?P<day>\d\d)
 (
  (T|\s+)
  (?P<hour>\d\d)
  (
   ([:])?(?P<minute>\d\d)
   (
    ([:])?(?P<second>\d\d)
    (
     ([.])?(?P<fraction>\d+)
    )?
   )?
  )?
 )?
 (
  (?P<tzzulu>Z)
  |
  (?P<tzoffset>[-+])
  (?P<tzhour>\d\d)
  ([:])?(?P<tzminute>\d\d)
 )?
 $

Other Proposals

This section needs a lot of clean-up. Proposals that have been relatively rejected need to be move to another section (or perhaps page), along with succinct summaries as to why they are untenable/infeasible/undesirable.

Remaining proposals probably need to be moved to proper brainstorming pages where they can be considered in a broader context.

Links to all proposals (whether relatively rejected or tentatively being considered) should be kept in this page for comparison purposes for this use case.

Tantek 04:50, 4 Sep 2008 (PDT)

strtime instructions as class names

Proposal by DavidLaban (alsuren on freenode) on 8 Jun 2008 It might be possible to have a slightly more readable/extensible/elegant format:

<span class="strtime format:_%d_%B_%Y_" > 16 March 1987 </span>

Notes:

  1. Underscores are used to replace whitespace, because otherwise the the formatting string will be split into an unordered set of class attributes by many parsers (thanks go to bogdanlazarsb and gsnedders on irc for explaining this to me).
  2. Some subset of the placeholders should be chosen from those which are supported by both python http://docs.python.org/lib/module-time.html and php http://uk3.php.net/manual/en/function.strftime.php
  3. A name for the class should be decided upon. strtime might not be the best name.
  4. Measures should be taken to avoid the format string accidentally conflicting with other valid classes (In the above example, I have prefixed it with the string "format:")
  5. It might be sensible (when parsing) to strip excess whitespace from the format string and contents. This is not done in this example.
  6. Example python code follows.
date = (1987,03,16,0,0,0,0,0,0)
format = " %d %B %Y "
# To encode:
classes = ["strtime"]
encoded_format = "format:" + format.replace(' ', '_')
classes.append(encoded_format)
content = time.strftime(format, birthday)
# ... dump classes and content into your document however you want

# To decode (assuming that you have managed to extract class and format from the document already):
if "strtime" in classes:
    possible_formats = [ item for item in classes if item.startswith('format:') ]
    assert len(possible_formats) == 1
    format = possible_formats[0].strip('format:').replace('_', ' ')
    date = time.strptime(content, format)

problems with strtime proposal

  1. Possible abuse of the class attribute. microformats limit the use of the class attribute to marking up additional semantics about the data, not for (potentially) arbitrary processing/programming instructions
    • HTML 4.01 Recommendation defines the class attribute as being "for general purpose processing by user agents". TobyInk 13:21, 8 Jun 2008 (PDT)
  2. Requires authors to think like programmers. The larger problem is that the proposal asks web authors to think like programmers, which severely limits the number of web authors which will be able to use the technique, since the vast majority of web authors are not programmers and have never heard of "strtime", whereas most authors (even people) on the web have seen dates like 2005-06-20 and easily understand what they mean.

In general, any publishing method that requires the author to think like a programmer is a non-starter. It is a much more of a barrier than simply using ISO8601/RFC3339, and that barrier is a far worse tradeoff than the duplication / DRY violation compromise. Tantek 09:52, 8 Jun 2008 (PDT)

Machine-data in class

The BBC (uf-dev archive, 20/06/08, "Using class for non-human data") has proposed as an alternative to the empty span and title solution to use the class name in the following way:

<span class="dtstart data-20051010T10:10:10-0100">10 o'clock on the 10th</span>

Pros:

Cons:

Discussion:

Experimental Parser Support

Cognition 0.1 alpha 10 will include experimental support for this pattern, and the Cognition web service already does. Notes:

date and time separation using value excerption

Moved to value excerption pattern brainstorming which is a better way of thinking about this.

HTML 5 <time> Element

See hCalendar issues

Plain Old English alternative to ISO date

Example (in English):

<abbr title="January 25th, 2008" class="dtstart" lang="en-us">1/25</abbr>
<span class="dtstart">January 25th, 2008</span>

If lang="en-us", the format of the date used in the title attribute must conform to dates writing rules in American English.

Example (in French):

<abbr title="25 Janvier 2008" class="dtstart" lang="fr">25/1</abbr>

If lang="fr", the format of the date used in the title attribute must conform to date writing rules in French.

Benefits

Disadvantages

Most extracted from discussion below.

Discussion

Notes

<object> element to represent dates

The idea was to do something like this:

<code><object data="20050125">January 25</object></code>

issues

Open issues related to this proposal. Some may require additional information to be acted upon / resolved.


resolved issues

Issues raised and resolved related to this proposal. Issues that are misconceptions (e.g. easily refuted by citing the HTML4 specification) are resolved by moving to the separate misconceptions section below with explanation/citation for why they are misconceptions.

misconceptions

external application only

This is false. From the HTML4.01 section on OBJECT:

Still others [other objects] may not require additional implementation information, i.e., the user agent itself may already know how to render that type of data (e.g., GIF images).

Thus browsers may render OBJECTs themselves, like images, and external applications are not necessarily required. For example IE5/Mac supported native rendering of PNG images even as objects, while other browsers at the time (2000) which supported OBJECT, only rendered PNG images via external plugins.

need width and height

This is false. Per the HTML4.01 section on OBJECT, the width and height attributes are "#IMPLIED" not "#REQUIRED".

Individual markup of each date/time component

A variant of this idea has been documented into a specific proposal and is being tested. Please see the value excerption pattern brainstorming: date and type separation and value-excerption-dt-separation-test page for updated details. Tantek 22:05, 24 February 2009 (UTC)

A combination of suggestions that originated from this post

This is suggested as a complementary alternative to datetime-design-pattern, when the use of the pattern is not possible due to accessibility reasons.

suggested class names:

For a complete datetime:

<span class="dtstart" lang="en-us">
<span class="date">
<span class="mo">October</span> <span class="day">5</span>, <span class="yr">2004</span>
<span> at 
<span class="time">
<span class="hr">6</span><span class="">PM</span>
</span>
</span>

date maybe not required since dtstart IS a date.

For a duration:

<span class="duration">
    <span class="h">1</span>:
    <span class="min">3</span>:
    <span class="s">42</span>
</span>

Issues

See Also

Datetime Design Pattern was last modified: Thursday, November 7th, 2013

Views