datetime-design-pattern-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
No edit summary
Line 9: Line 9:


== Comment l'utiliser ==
== Comment l'utiliser ==
* envelopper le datetime humainement lisible que vous voulez pour le rendre lisible par une machine avec <code>&lt;abbr></code>
* envelopper le datetime humainement lisible que vous voulez pour le rendre lisible par une machine avec <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 ou une date comme la valeur.
 
== Usages actuels ==
 
Le modèle qui est maintenant utilisé dans [[hcalendar-fr|hCalendar]] et [[hreview-fr|hReview]] est quelque chose comme ça :
 
<pre>&lt;abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ"&gt;Date Heure&lt;/abbr&gt;</pre>
 
où foo est le nom de classe sémantique qui est appliqué à ces date/heure, le titre de la &lt;abbr&gt; est une date/heure ISO 8601 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 :
 
<pre>&lt;abbr class="foo" title="AAAA-MM-JJTHH:MM:SSZ"&gt;Date Heure&lt;/abbr&gt;</pre>
 
avec un "Z" unique comme sur [http://fr.wikipedia.org/wiki/ISO_8601 ISO 8601]
 
== Profil de ISO8601 ==
 
Nous recommandons que tout [[microformat-fr|microformat]] utilisant le modèle du date-time-design utilise un profil de ISO8601.  Il existe actuellement deux profils largement utilisés qui DEVRAIENT être réutilisés.
 
* RFC 3339
* [http://www.w3.org/TR/NOTE-datetime W3C Note sur les Datetimes]
 
 
== 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 &lt;abbr&gt; 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]
 
 
 
== 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>&lt;[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

Revision as of 07:42, 11 April 2007

Datetime Design Pattern

Ceci est une page pour explorer un pattern de design pour datetime.

Intention

  • Utiliser le datetime-design-pattern pour faire que les dates et heures puissent être lisibiles 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 lisibiles par les humains pour le microformat hCalendar.

Comment l'utiliser

  • envelopper le datetime humainement lisible que vous voulez pour le rendre lisible par une machine avec
Retrieved from "http://microformats.org/wiki/index.php?title=datetime-design-pattern-fr&oldid=15465"