Datetime Design Pattern

Jump to: navigation, search


Ceci est une page pour explorer un pattern de design pour la date et l'heure.

Contents

Intention

Besoin Pratique

Comment l'utiliser

Pour les dates-horaires ISO8601, utilisez à la place le modèle de classe value pour une meilleure accessibilité.

Usages actuels

Le modèle désormais disponible faisant partie de hAtom, de hCalendar et hReview est :

<abbr class="foo" title="AAAA-MM-JJTHH:MM:SS+ZZ:ZZ">Date Heure</abbr>

où "foo" est le nom de classe sémantique qui est appliqué à ces date/heure, le titre de l'<abbr> est une date/heure ISO 8601, avec un niveau approprié de spécificité, et "Date Heure" est une représentation conviviale et humaine de la même date et heure.

Une alternative, si vous utilisez des chronodatages basés sur UTC, serait :

<abbr class="foo" title="AAAA-MM-JJTHH:MM:SSZ">Date Heure</abbr>

avec un "Z" unique comme selon ISO 8601


Note : les chaînes title de la forme "AAAA-MM-JTHH:MM:SSZ" peuvent être difficiles à lire et comprendre pour les humains, de ce fait, utilisez le modèle de classe value pour les dates heures.

Ruby

Ruby : Un moyen facile d'avoir ce format à partir d'une DateHeure est ceci :

DateTime.now.to_s

Ou alternativement, si vous travaillez avec des objets Time :

require 'time'
Time.now.iso8601

Profil de ISO8601

Tout microformat utilisant le date-time-design-pattern DEVRAIT utiliser un profil ISO8601. Il existe actuellement deux profils largement utilisés qui DEVRAIENT être réutilisés.

problématiques d'accessibilité

Notez aussi que les problématiques d'accessibilité ont considérablement diminué, et ont été même élimnées au moment d'utiliser le date-design-pattern, un sous-ensemble du datetime-design-pattern.

Discussion

Cette section a besoin d'un jardinage significatif, et peut-être qu'archiver les discussions qui sont initialement historiques, comme le value-class-pattern sert à résoudre la plupart des problématiques soulevées ici. Tantek

Est-ce que cela ne pourrait pas être vu comme un microformat en soi ?

--User:DimitriGlazkov

Ce le pourrait, mais inventer un microformat pour la recherche d'inventer un microformat va à l'encontre des principes des microformats. S'il existe un problème spécifique du vrai monde (et des cas d'utilisation) qu'un tel microformat élémentaire résoudrait, alors ça vaudrait la peine de considérer ça.

A ce stade, alors il est mieux de conserver le concept datetime simplement comme un modèle de design de microformat <abbr> datetime pour être utilisé dans de _véritables_ microformats qui ont un besoin pratique démontré.

-- Tantek

Extrait de #microformats le 18 août. Editez svp !

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

L'expression régulière suivante (parsé VERBOSE) devrait démonter à part un datetime et couvrir beaucoup de cas légèrement cassés vus dans la jungle. Ceci a été testé sous 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)
 )?
 $


Autres Propositions

Cette section a besoin avant traduction de beaucoup de nettoyage. Les propositions ont été relativement rejetées, on besoin de migrer sur une autre section (ou peut-être une page) avec des résumés succincts des raisons pour lesquelles elles sont intenables/infaisables/indésirables.

Les propositions restantes ont besoin de migrer vers les propres pages de brainstorming où elles peuvent être considérées dans un contexte plus large.

Les liens vers toutes les propositions (qu'elles soient relativement rejetées ou possiblement étudiées) devraient être conservés dans cette page à des fins de comparaison pour ce cas d'usage.

Tantek 04:50, 4 Sep 2008 (PDT)

instructions strtime comme noms de classes

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)

problèmes avec la propositon strtime

  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)

donnée-machine dans la classe

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:

support expérimental parseur

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

séparation date et heure en utilisant l'extraction de value

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

élement HTML 5 <time>

See hCalendar issues

Plain Old English alternative to ISO date

Example (in English):

<abbr title="January 25th, 2008" class="dstart" lang="en-us">1/25</abbr>
<span class="dstart">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="dstart" 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.

avantages

inconvénients

Most extracted from discussion below.

Discussion

Notes

élément <object> pour représenter des dates

The idea was to do something like this:

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

problématiques

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


problématiques résolues

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.

idées fausses

application exerrne seulement

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.

besoin de width et height

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

maquage individuel de chaque composant date/heure

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="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>

date maybe not required since dstart 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>

problématiques


Voir aussi

Datetime Design Pattern was last modified: Sunday, September 22nd, 2013

Views