xeps/xep-0082.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
  <!ENTITY % ents SYSTEM "../jep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<header>
  <title>Jabber Date and Time Profiles</title>
  <abstract>This JEP specifies a standardization of ISO 8601 profiles and their lexical representation for use in Jabber/XMPP protocol extensions.</abstract>
  &LEGALNOTICE;
  <number>0082</number>
  <status>Active</status>
  <type>Informational</type>
  <jig>Standards JIG</jig>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>ISO 8601</spec>
    <spec>XML Schema Part 2</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>N/A</shortname>
  &stpeter;
  <revision>
    <version>1.0</version>
    <date>2003-05-28</date>
    <initials>psa</initials>
    <remark>Per a vote of the Jabber Council, advanced status to Active.</remark>
  </revision>
  <revision>
    <version>0.6</version>
    <date>2003-05-22</date>
    <initials>psa</initials>
    <remark>Added examples; added section on migration.</remark>
  </revision>
  <revision>
    <version>0.5</version>
    <date>2003-05-19</date>
    <initials>psa</initials>
    <remark>Adjusted wording regarding several XML Schema references; added implementation notes.</remark>
  </revision>
  <revision>
    <version>0.4</version>
    <date>2003-05-16</date>
    <initials>psa</initials>
    <remark>Updated to refer to XML Schema datatypes; removed "Precise Datetime" profile; added "Time" profile for recurring events.</remark>
  </revision>
  <revision>
    <version>0.3</version>
    <date>2003-05-08</date>
    <initials>psa</initials>
    <remark>Clarified registration format, deleted references to undocumented protocols, removed implementation notes.</remark>
  </revision>
  <revision>
    <version>0.2</version>
    <date>2003-04-28</date>
    <initials>psa</initials>
    <remark>Added "Precise Datetime" profile.</remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2003-04-21</date>
    <initials>psa</initials>
    <remark>Initial version.</remark>
  </revision>
</header>
<section1 topic='Introduction'>
  <p>A number of Jabber protocols specify that dates and times should follow the format defined in &iso8601;. Unfortunately, ISO 8601 provides a great deal of flexibility with regard to the possible date and time "profiles" <note>The concept of an ISO 8601 profile is used in both RFC 3339 (<link url='http://www.ietf.org/rfc/rfc3339.txt'>http://www.ietf.org/rfc/rfc3339.txt</link>) and a W3C Note (<link url='http://www.w3.org/TR/NOTE-datetime'>http://www.w3.org/TR/NOTE-datetime</link>).</note> as well as their lexical representation. While that flexibility can lead to confusion, it is also true that the Jabber community has tended to use only a few restricted profiles of ISO 8601 dates and times (albeit with inconsistent lexical representations). This JEP formalizes those profiles and their lexical representation through reference to the datatypes defined in &w3xmlschema2;.</p>
</section1>
<section1 topic="Terminology">
  <section2 topic='Time Terms'>
    <p>The following acronyms and characters are used herein to represent time-related concepts:</p>
    <table caption='Acronyms and Characters'>
      <tr><th>Term</th><th>Definition</th></tr>
      <tr><td>CCYY</td><td>four-digit year portion of Date</td></tr>
      <tr><td>MM</td><td>two-digit month portion of Date</td></tr>
      <tr><td>DD</td><td>two-digit day portion of Date</td></tr>
      <tr><td>-</td><td>ISO 8601 separator among Date portions</td></tr>
      <tr><td>T</td><td>ISO 8601 separator between Date and Time</td></tr>
      <tr><td>hh</td><td>two-digit hour portion of Time (00 through 23)</td></tr>
      <tr><td>mm</td><td>two-digit minutes portion of Time (00 through 59)</td></tr>
      <tr><td>ss</td><td>two-digit seconds portion of Time (00 through 59)</td></tr>
      <tr><td>:</td><td>ISO 8601 separator among Time portions</td></tr>
      <tr><td>.</td><td>ISO 8601 separator between seconds and milliseconds</td></tr>
      <tr><td>sss</td><td>fractional second addendum to Time (MAY contain any number of digits)</td></tr>
      <tr><td>TZD</td><td>Time Zone Definition (either "Z" for UTC or "[+|-]hh:mm" for a specific time zone)</td></tr>
    </table>
  </section2>
</section1>
<section1 topic='Profiles'>
   <p>Three profiles are defined herein.</p>
   <section2 topic='Date'>
     <p>The Date profile defines a date without including the time of day. The lexical representation is as follows:</p>
     <code>
     CCYY-MM-DD
     </code>
     <p>This profile is equivalent to the 'date' datatype defined in XML Schema <note>The 'date' datatype is defined at &lt;<link url='http://www.w3.org/TR/xmlschema-2/#date'>http://www.w3.org/TR/xmlschema-2/#date</link>&gt;.</note>. When an XML schema is used to define a Jabber protocol that uses this profile, the datatype MUST be an XML Schema 'date'. If there are differences between the description in this JEP and those in XML Schema, the latter overrule.</p>
     <example caption='The date of American independence'>
     1776-07-04
     </example>
   </section2>
   <section2 topic='DateTime'>
     <p>The DateTime profile is used to specify a non-recurring moment in time to an accuracy of seconds (or, optionally, fractions of a second). The format is as follows:</p>
     <code>
     CCYY-MM-DDThh:mm:ss[.sss]TZD
     </code>
     <p>The Time Zone Definition is mandatory and MUST be either UTC (denoted by addition of the character 'Z' to the end of the string) or some offset from UTC (denoted by addition of '[+|-]' and 'hh:mm' to the end of the string). The fractions of a second are optional and MAY be ignored if included (although a Jabber protocol using the DateTime profile MAY require the fractions of a second).</p>
     <p>This profile is equivalent to the 'dateTime' datatype defined in XML Schema  <note>The 'dateTime' datatype is defined at &lt;<link url='http://www.w3.org/TR/xmlschema-2/#dateTime'>http://www.w3.org/TR/xmlschema-2/#dateTime</link>&gt;.</note>. When an XML schema is used to define a Jabber protocol that uses this profile, the datatype MUST be an XML Schema 'dateTime'. If there are differences between the description in this JEP and those in XML Schema, the latter overrule.</p>
     <example caption='Datetime of the first human steps on the Moon (UTC)'>
     1969-07-21T02:56:15Z
     </example>
     <example caption='Datetime of the first human steps on the Moon (Houston time)'>
     1969-07-20T21:56:15-05:00
     </example>
   </section2>
   <section2 topic='Time'>
     <p>The Time profile is used to specify an instant of time that recurs (e.g., every day). The lexical representation is as follows:</p>
     <code>
     hh:mm:ss[.sss][TZD]
     </code>
     <p>The Time Zone Definition is optional; if included, it MUST be either UTC (denoted by addition of the character 'Z' to the end of the string) or some offset from UTC (denoted by addition of '[+|-]' and 'hh:mm' to the end of the string). The fractions of a second are optional and MAY be ignored if included (although a Jabber protocol using the DateTime profile MAY require the fractions of a second).</p>
     <p>This profile is equivalent to the 'time' datatype defined in XML Schema <note>The 'time' datatype is defined at &lt;<link url='http://www.w3.org/TR/xmlschema-2/#time'>http://www.w3.org/TR/xmlschema-2/#time</link>&gt;.</note>. When an XML schema is used to define a Jabber protocol that uses this profile, the datatype MUST be an XML Schema 'time'. If there are differences between the description in this JEP and those in XML Schema, the latter overrule.</p>
     <example caption='Time for tea'>
     16:00:00
     </example>
   </section2>
</section1>
<section1 topic='Migration'>
  <p>Some existing Jabber protocols use a different lexical representation for datetimes than the representation defined in XML Schema and specified by this JEP. These are &jep0090;, &jep0091;, and &jep0009;. (The representation of dates in &jep0054; matches that specified herein.) These older protocols represent datetimes as follows:</p>
  <code>
  CCYYMMDDThh:mm:ss
  </code>
  <p>The primary standard notation recommended by ISO 8601 includes the separators ("-" for dates and ":" for times), although ISO 8601 allows omission of the separators for applications in which compactness is more important than human readability. It is arguable whether Jabber applications using 'jabber:iq:time' and 'jabber:x:delay' require such compactness, but these protocols are in wide use today and have been implemented using the format shown above. Therefore, applications receiving data in those namespaces SHOULD be liberal in what they accept by handling datetimes either in the "CCYYMMDDThh:mm:ss" format or in the lexical representation defined in XML Schema and specified by this JEP. Applications generating data in those namespaces SHOULD use the existing format ("CCYYMMDDThh:mm:ss"), and are effectively "grandfathered" with respect to the date and time formats defined herein. While eventually it would be good to deprecate the older datetime representation for these protocols, the schedule for such deprecation (if any) shall be specified in official JEPs for these older protocols.</p>
  <p>Jabber-RPC is a special case, since the specification for &xmlrpc; includes only one example for datetimes, which is of the format "CCYYMMDDThh:mm:ss". Apparently many implementations of XML-RPC have taken this lexical representation as canonical, and do not support any other representation; because Jabber-RPC normally provides an interface to software that is outside the Jabber network, it is prudent for Jabber-RPC implementations to generate dates in the format shown in the XML-RPC specification, not that defined in this JEP.</p>
  <p>New protocols approved by the Jabber Software Foundation MUST use the lexical representations defined in this JEP.</p>
</section1>
<section1 topic='Implementation Notes'>
  <p>The 'date', 'dateTime', and 'time' datatypes defined in XML Schema address several "edge cases" such as dates before the year 0000 and after the year 9999, as well as odd timezones no longer in use; most Jabber applications can safely ignore these edge cases, since it is highly unlikely that a Jabber entity will generate such representations.</p>
</section1>
<section1 topic='Security Considerations'>
  <p>There are no security features or concerns related to this proposal.</p>
</section1>
<section1 topic='IANA Considerations'>
  <p>This JEP requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
  <p>This JEP requires no interaction with the &REGISTRAR;.</p>
</section1>
</jep>