datetime-design-pattern-fr

2008-12-16T18:55:22Z

NooloTamon: domvarri

zeldarelc
''Cette page est un draft''

<h1> Datetime Design Pattern </h1>
Ceci est une page pour explorer un pattern de design pour datetime.

== Intention ==
* Utiliser le [[datetime-design-pattern-fr|datetime-design-pattern]] pour faire que les dates et heures puissent Ãªtre lisibles pour des humains et aussi lisibles formellement par des machines.

== Besoin Pratique ==
* Ce modÃ¨le de design a Ã©mergÃ© comme un rÃ©sultat pour rÃ©soudre le besoin pratique pour des dates lisibles par les humains pour le microformat [[hcalendar-fr|hCalendar]].

== Comment l'utiliser ==
* envelopper le datetime humainement lisible que vous voulez pour le rendre lisible par une machine avec <code><abbr></code>
* comme selon le [[class-design-pattern-fr|class-design-pattern]], ajoutez l'attribut <code>class</code> appropriÃ© Ã l'Ã©lÃ©ment <code>abbr</code>
* ajoutez un attribut <code>title</code> Ã l'Ã©lÃ©ment <code>abbr</code> avec le datetime ISO8601 lisible par une machine ou date comme la valeur.

== Usages actuels ==
Le modÃ¨le qui est maintenant disponibles comme partie de [[hatom-fr|hAtom]], de [[hcalendar-fr|hCalendar]] et [[hreview-fr|hReview]] est :

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

oÃ¹ foo est le nom de classe sÃ©mantique qui est appliquÃ© Ã ces date/heure, le titre de <abbr> est une date/heure ISO 8601 et "Date Heure", avec un niveau appropriÃ© de spÃ©cificitÃ©, et "Date Time" 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 :

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

avec un "Z" unique comme selon [[iso-8601-fr|ISO 8601]]

== Profil de ISO8601 ==

Tout [[microformat-fr|microformat]] utilisant le date-time-design-pattern {{should-fr}} utiliser un profil [[iso-8601|ISO8601]]. Il existe actuellement deux profils largement utilisÃ©s qui {{should-fr}} (DEVRAIENT) Ãªtre rÃ©utilisÃ©s.

* RFC 3339
* [http://www.w3.org/TR/NOTE-datetime W3C Note sur les Datetimes]

==ProblÃ©matiques d'accessibilitÃ©==

Note: There are some accessibility issues [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.

== Discussion ==

Ce modÃ¨le va probablement devenir hautement rÃ©utilisable.

--[[User:RyanKing]]

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Ã©.

-- [http://tantek.com/log/ Tantek]

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

<pre>
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.
</pre>

Here's an exhaustive [http://www.imc.org/atom-syntax/mail-archive/msg13103.html 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 [http://www.imc.org/atom-syntax/mail-archive/msg13244.html Sam Ruby] and [http://www.imc.org/atom-syntax/mail-archive/msg13248.html 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. --[http://franklinmint.fm Robert Sayre]

<pre>
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
</pre>

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. - [http://suda.co.uk/ 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. - [http://bitworking.org Joe Gregorio]

---

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

# 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.''
# 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 [http://www.w3.org/TR/WCAG20-TECHS/#H28 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.''
# 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]].''
# 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.

<pre><nowiki>
^
(?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)
)?
$
</nowiki></pre>

== Voir aussi ==

* [[Main_Page-fr#Design_Patterns|Tous les design patterns microformat]]
* [[abbr-design-pattern-fr]] est utilisÃ© par [[datetime-design-pattern-fr|datetime-design-pattern]]
* La dÃ©finition HTML 4.01 de l'Ã©lÃ©ment <code><[http://www.la-grange.net/w3c/html4.01/struct/text.html#edef-ABBR abbr]></code>
* 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]
* Markus Kuhn : [http://www.cl.cam.ac.uk/~mgk25/iso-time.html A summary of the international standard date and time notation]
* Wikipedia : [http://fr.wikipedia.org/wiki/ISO_8601 ISO 8601] norme internationale de dÃ©finition des dates et heures

Microformats Wiki - User contributions [en]

datetime-design-pattern-fr