| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" |
| "http://www.w3.org/TR/html4/loose.dtd"> |
| <html> |
| <head> |
| <meta name="generator" content= |
| "HTML Tidy for HTML5 for Apple macOS version 5.6.0"> |
| <meta http-equiv="Content-Type" content= |
| "text/html; charset=utf-8"> |
| <meta http-equiv="Content-Language" content="en-us"> |
| <link rel="stylesheet" href= |
| "http://www.unicode.org/reports/reports.css" type="text/css"> |
| <title>UTS #35: Unicode LDML: Dates</title> |
| <style type="text/css"> |
| <!-- |
| .dtd { |
| font-family: monospace; |
| font-size: 90%; |
| background-color: #CCCCFF; |
| border-style: dotted; |
| border-width: 1px; |
| } |
| |
| .xmlExample { |
| font-family: monospace; |
| font-size: 80% |
| } |
| |
| .blockedInherited { |
| font-style: italic; |
| font-weight: bold; |
| border-style: dashed; |
| border-width: 1px; |
| background-color: #FF0000 |
| } |
| |
| .inherited { |
| font-weight: bold; |
| border-style: dashed; |
| border-width: 1px; |
| background-color: #00FF00 |
| } |
| |
| .element { |
| font-weight: bold; |
| color: red; |
| } |
| |
| .attribute { |
| font-weight: bold; |
| color: maroon; |
| } |
| |
| .attributeValue { |
| font-weight: bold; |
| color: blue; |
| } |
| |
| li, p { |
| margin-top: 0.5em; |
| margin-bottom: 0.5em |
| } |
| |
| h2, h3, h4, table { |
| margin-top: 1.5em; |
| margin-bottom: 0.5em; |
| } |
| --> |
| </style> |
| </head> |
| <body> |
| <table class="header" width="100%"> |
| <tr> |
| <td class="icon"><a href="http://unicode.org"><img alt= |
| "[Unicode]" src="http://unicode.org/webscripts/logo60s2.gif" |
| width="34" height="33" style= |
| "vertical-align: middle; border-left-width: 0px; border-bottom-width: 0px; border-right-width: 0px; border-top-width: 0px;"></a> |
| <a class="bar" href= |
| "http://www.unicode.org/reports/">Technical Reports</a></td> |
| </tr> |
| <tr> |
| <td class="gray"> </td> |
| </tr> |
| </table> |
| <div class="body"> |
| <h2 style="text-align: center">Unicode Technical Standard #35</h2> |
| <h1>Unicode Locale Data Markup Language (LDML)<br> |
| Part 4: Dates</h1> |
| <!-- At least the first row of this header table should be identical across the parts of this UTS. --> |
| <table border="1" cellpadding="2" cellspacing="0" class="wide"> |
| <tr> |
| <td>Version</td> |
| <td>35</td> |
| </tr> |
| <tr> |
| <td>Editors</td> |
| <td>Peter Edberg and <a href= |
| "tr35.html#Acknowledgments">other CLDR committee |
| members</a></td> |
| </tr> |
| </table> |
| <p>For the full header, summary, and status, see <a href= |
| "tr35.html">Part 1: Core.</a></p> |
| <h3><i>Summary</i></h3> |
| <p>This document describes parts of an XML format |
| (<i>vocabulary</i>) for the exchange of structured locale data. |
| This format is used in the <a href= |
| "http://cldr.unicode.org/">Unicode Common Locale Data |
| Repository</a>.</p> |
| <p>This is a partial document, describing only those parts of |
| the LDML that are relevant for date, time, and time zone |
| formatting. For the other parts of the LDML see the <a href= |
| "tr35.html">main LDML document</a> and the links above.</p> |
| <h3><i>Status</i></h3> |
| |
| <!-- NOT YET APPROVED |
| <p> |
| <i class="changed">This is a<b><font color="#ff3333"> |
| draft </font></b>document which may be updated, replaced, or superseded by |
| other documents at any time. Publication does not imply endorsement |
| by the Unicode Consortium. This is not a stable document; it is |
| inappropriate to cite this document as other than a work in |
| progress. |
| </i> |
| </p> |
| END NOT YET APPROVED --> |
| <!-- APPROVED --> |
| <p><i>This document has been reviewed by Unicode members and |
| other interested parties, and has been approved for publication |
| by the Unicode Consortium. This is a stable document and may be |
| used as reference material or cited as a normative reference by |
| other specifications.</i></p> |
| <!-- END APPROVED --> |
| |
| <p><i>This document has been reviewed by Unicode members and |
| other interested parties, and has been approved for publication |
| by the Unicode Consortium. This is a stable document and may be |
| used as reference material or cited as a normative reference by |
| other specifications.</i></p><!-- END APPROVED --> |
| <blockquote> |
| <p><i><b>A Unicode Technical Standard (UTS)</b> is an |
| independent specification. Conformance to the Unicode |
| Standard does not imply conformance to any UTS.</i></p> |
| </blockquote> |
| <p><i>Please submit corrigenda and other comments with the CLDR |
| bug reporting form [<a href="tr35.html#Bugs">Bugs</a>]. Related |
| information that is useful in understanding this document is |
| found in the <a href="tr35.html#References">References</a>. For |
| the latest version of the Unicode Standard see [<a href= |
| "tr35.html#Unicode">Unicode</a>]. For a list of current Unicode |
| Technical Reports see [<a href= |
| "tr35.html#Reports">Reports</a>]. For more information about |
| versions of the Unicode Standard, see [<a href= |
| "tr35.html#Versions">Versions</a>].</i></p> |
| <!-- This section of Parts should be identical in all of the parts of this UTS. --> |
| <h2><a name="Parts" href="#Parts" id="Parts">Parts</a></h2> |
| <p>The LDML specification is divided into the following |
| parts:</p> |
| <ul class="toc"> |
| <li>Part 1: <a href="tr35.html#Contents">Core</a> (languages, |
| locales, basic structure)</li> |
| <li>Part 2: <a href="tr35-general.html#Contents">General</a> |
| (display names & transforms, etc.)</li> |
| <li>Part 3: <a href="tr35-numbers.html#Contents">Numbers</a> |
| (number & currency formatting)</li> |
| <li>Part 4: <a href="tr35-dates.html#Contents">Dates</a> |
| (date, time, time zone formatting)</li> |
| <li>Part 5: <a href= |
| "tr35-collation.html#Contents">Collation</a> (sorting, |
| searching, grouping)</li> |
| <li>Part 6: <a href= |
| "tr35-info.html#Contents">Supplemental</a> (supplemental |
| data)</li> |
| <li>Part 7: <a href= |
| "tr35-keyboards.html#Contents">Keyboards</a> (keyboard |
| mappings)</li> |
| </ul> |
| <h2><a name="Contents" href="#Contents" id="Contents">Contents |
| of Part 4, Dates</a></h2> |
| <!-- START Generated TOC: CheckHtmlFiles --> |
| <ul class="toc"> |
| <li>1 <a href= |
| "#Overview_Dates_Element_Supplemental">Overview: Dates |
| Element, Supplemental Date and Calendar Information</a></li> |
| <li>2 <a href="#Calendar_Elements">Calendar Elements</a> |
| <ul class="toc"> |
| <li>2.1 <a href="#months_days_quarters_eras">Elements |
| months, days, quarters, eras</a></li> |
| <li>2.2 <a href="#monthPatterns_cyclicNameSets">Elements |
| monthPatterns, cyclicNameSets</a></li> |
| <li>2.3 <a href="#dayPeriods">Element dayPeriods</a></li> |
| <li>2.4 <a href="#dateFormats">Element |
| dateFormats</a></li> |
| <li>2.5 <a href="#timeFormats">Element |
| timeFormats</a></li> |
| <li>2.6 <a href="#dateTimeFormats">Element |
| dateTimeFormats</a> |
| <ul class="toc"> |
| <li>2.6.1 <a href="#dateTimeFormat">Element |
| dateTimeFormat</a> |
| <ul class="toc"> |
| <li>Table: <a href= |
| "#Date_Time_Combination_Examples">Date-Time |
| Combination Examples</a></li> |
| </ul> |
| </li> |
| <li>2.6.2 <a href= |
| "#availableFormats_appendItems">Elements |
| availableFormats, appendItems</a> |
| <ul class="toc"> |
| <li>2.6.2.1 <a href= |
| "#Matching_Skeletons">Matching Skeletons</a></li> |
| <li>2.6.2.2 <a href= |
| "#Missing_Skeleton_Fields">Missing Skeleton |
| Fields</a></li> |
| </ul> |
| </li> |
| <li>2.6.3 <a href="#intervalFormats">Element |
| intervalFormats</a></li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| <li>3 <a href="#Calendar_Fields">Calendar Fields</a></li> |
| <li>4 <a href="#Supplemental_Calendar_Data">Supplemental |
| Calendar Data</a> |
| <ul class="toc"> |
| <li>4.1 <a href="#Calendar_Data">Calendar Data</a></li> |
| <li>4.2 <a href="#Calendar_Preference_Data">Calendar |
| Preference Data</a></li> |
| <li>4.3 <a href="#Week_Data">Week Data</a></li> |
| <li>4.4 <a href="#Time_Data">Time Data</a></li> |
| <li>4.5 <a href="#Day_Period_Rule_Sets">Day Period Rule |
| Sets</a> |
| <ul class="toc"> |
| <li>4.5.1 <a href="#Day_Period_Rules">Day Period |
| Rules</a> |
| <ul class="toc"> |
| <li>4.5.1.1 <a href="#Fixed_periods">Fixed |
| periods</a></li> |
| <li>4.5.1.2 <a href="#Variable_periods">Variable |
| periods</a></li> |
| <li>4.5.1.3 <a href= |
| "#Parsing_Day_Periods">Parsing Day |
| Periods</a></li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| <li>5 <a href="#Time_Zone_Names">Time Zone Names</a> |
| <ul class="toc"> |
| <li>Table: <a href= |
| "#timeZoneNames_Elements_Used_for_Fallback"><timeZoneNames> |
| Elements Used for Fallback</a></li> |
| <li>5.1 <a href="#Metazone_Names">Metazone Names</a></li> |
| </ul> |
| </li> |
| <li>6 <a href="#Supplemental_Time_Zone_Data">Supplemental |
| Time Zone Data</a> |
| <ul class="toc"> |
| <li>6.1 <a href="#Metazones">Metazones</a></li> |
| <li>6.2 <a href="#Windows_Zones">Windows Zones</a></li> |
| <li>6.3 <a href="#Primary_Zones">Primary Zones</a></li> |
| </ul> |
| </li> |
| <li>7 <a href="#Using_Time_Zone_Names">Using Time Zone |
| Names</a> |
| <ul class="toc"> |
| <li>7.1 <a href="#Time_Zone_Format_Terminology">Time Zone |
| Format Terminology</a></li> |
| <li>7.2 <a href="#Time_Zone_Goals">Goals</a></li> |
| <li>7.3 <a href="#Time_Zone_Parsing">Parsing</a></li> |
| </ul> |
| </li> |
| <li>8 <a href="#Date_Format_Patterns">Date Format |
| Patterns</a> |
| <ul class="toc"> |
| <li>Table: <a href="#Date_Format_Pattern_Examples">Date |
| Format Pattern Examples</a></li> |
| <li><a href="#Date_Field_Symbol_Table">Date Field Symbol |
| Table</a></li> |
| <li>8.1 <a href="#Localized_Pattern_Characters">Localized |
| Pattern Characters (deprecated)</a></li> |
| <li>8.2 <a href="#Date_Patterns_AM_PM">AM / PM</a></li> |
| <li>8.3 <a href="#Date_Patterns_Eras">Eras</a></li> |
| <li>8.4 <a href="#Date_Patterns_Week_Of_Year">Week of |
| Year</a></li> |
| <li>8.5 <a href="#Date_Patterns_Week_Elements">Week |
| Elements</a></li> |
| </ul> |
| </li> |
| <li>9 <a href="#Parsing_Dates_Times">Parsing Dates and |
| Times</a></li> |
| </ul><!-- END Generated TOC: CheckHtmlFiles --> |
| <h2>1 <a name="Overview_Dates_Element_Supplemental" href= |
| "#Overview_Dates_Element_Supplemental" id= |
| "Overview_Dates_Element_Supplemental">Overview: Dates Element, |
| Supplemental Date and Calendar Information</a></h2> |
| <p class="dtd"><!ELEMENT dates (alias | (calendars?, |
| fields?, timeZoneNames?, special*)) ></p> |
| <p>The LDML top-level <dates> element contains |
| information regarding the format and parsing of dates and |
| times, the formatting of date/time intervals, and the the |
| naming of various calendar elements.</p> |
| <ul> |
| <li>The <calendars> element is described in section 2 |
| <a href="#Calendar_Elements">Calendar Elements</a>.</li> |
| <li>The <fields> element is described in section 3 |
| <a href="#Calendar_Fields">Calendar Fields</a>.</li> |
| <li>The <timeZoneNames> element is described in section |
| 5 <a href="#Time_Zone_Names">Time Zone Names</a>.</li> |
| <li>The formats use pattern characters described in section 8 |
| <a href="#Date_Format_Patterns">Date Format |
| Patterns</a>.</li> |
| </ul> |
| <p class="dtd"><!ELEMENT supplementalData ( …, |
| calendarData?, calendarPreferenceData?, weekData?, timeData?, |
| …, timezoneData?, …, metazoneInfo?, …, dayPeriodRuleSet*, |
| metaZones?, primaryZones?, windowsZones?, …) ></p> |
| <p>The relevant top-level supplemental elements are listed |
| above.</p> |
| <ul> |
| <li>The <calendarData>, <calendarPreferenceData>, |
| <weekData>, <timeData>, and |
| <dayPeriodRuleSet> elements are described in section 4 |
| <a href="#Supplemental_Calendar_Data">Supplemental Calendar |
| Data</a>.</li> |
| <li>The <timezoneData> element is deprecated and no |
| longer used; the <metazoneInfo> element is deprecated |
| at this level, and is now only used as a sub-element of |
| <metaZones>.</li> |
| <li>The <metaZones>, <primaryZones>, and |
| <windowsZones> elements are described in section 6 |
| <a href="#Supplemental_Time_Zone_Data">Supplemental Time Zone |
| Data</a>.</li> |
| </ul> |
| <h2>2 <a name="Calendar_Elements" href="#Calendar_Elements" id= |
| "Calendar_Elements">Calendar Elements</a></h2> |
| <p class="dtd"><!ELEMENT calendars (alias | (calendar*, |
| special*)) ><br> |
| <!ELEMENT calendar (alias | (months?, monthPatterns?, days?, |
| quarters?, dayPeriods?, eras?, cyclicNameSets?, dateFormats?, |
| timeFormats?, dateTimeFormats?, special*))><br> |
| <!ATTLIST calendar type NMTOKEN #REQUIRED ></p> |
| <p>The <calendars> element contains multiple |
| <calendar> elements, each of which specifies the fields |
| used for formatting and parsing dates and times according to |
| the calendar specified by the type attribute (e.g. "gregorian", |
| "buddhist", "islamic"). The behaviors for different calendars |
| in a locale may share certain aspects, such as the names for |
| weekdays. They differ in other respects; for example, the |
| Japanese calendar is similar to the Gregorian calendar but has |
| many more eras (one for each Emperor), and years are numbered |
| within each era. All calendar data inherits either from the |
| Gregorian calendar or other calendars in the same locale (and |
| if not present there then from the parent up to root), or else |
| inherits directly from the parent locale for certain calendars, |
| so only data that differs from what would be inherited needs to |
| be supplied. See <i><a href= |
| "tr35.html#Multiple_Inheritance">Multiple |
| Inheritance</a></i>.</p> |
| <p>Each calendar provides—directly or indirectly—two general |
| types of data:</p> |
| <ul> |
| <li><em>Calendar symbols, such as names for eras, months, |
| weekdays, and dayPeriods.</em> Names for weekdays, quarters |
| and dayPeriods are typically inherited from the Gregorian |
| calendar data in the same locale. Symbols for eras and months |
| should be provided for each calendar, except that the |
| "Gregorian-like" Buddhist, Japanese, and Minguo (ROC) |
| calendars also inherit their month names from the Gregorian |
| data in the same locale.</li> |
| <li><em>Format data for dates, times, and date-time |
| intervals.</em> Non-Gregorian calendars inherit standard time |
| formats (in the <timeFormats> element) from the |
| Gregorian calendar in the same locale. Most non-Gregorian |
| calendars (other than Chinese and Dangi) inherit general date |
| format data (in the <dateFormats> and |
| <dateTimeFormats> elements) from the "generic" calendar |
| format data in the same locale, which in turn inherits from |
| Gregorian.</li> |
| </ul> |
| <p>Calendars that use cyclicNameSets and monthPatterns (such as |
| Chinese and Dangi) have additional symbols and distinct |
| formats, and typically inherit these items (along with month |
| names) from their parent locales, instead of inheriting them |
| from Gregorian or generic data in the same locale.</p> |
| <p>The primary difference between Gregorian and "generic" |
| format data is that date formats in "generic" usually include |
| era with year, in order to provide an indication of which |
| calendar is being used (Gregorian calendar formats may also |
| commonly include era with year when Gregorian is not the |
| default calendar for the locale). Otherwise, the "generic" date |
| formats should normally be consistent with those in the |
| Gregorian calendar. The "generic" calendar formats are intended |
| to provide a consistent set of default formats for |
| non-Gregorian calendars in the locale, so that in most cases |
| the only data items that need be provided for non-Gregorian |
| calendars are the era names and month names (and the latter |
| only for calendars other than Buddhist, Japanese, and Minguo, |
| since those inherit month names from Gregorian).</p> |
| <h3>2.1 <a name="months_days_quarters_eras" href= |
| "#months_days_quarters_eras" id= |
| "months_days_quarters_eras">Elements months, days, quarters, |
| eras</a></h3> |
| <p class="dtd"><!ELEMENT months ( alias | (monthContext*, |
| special*)) ><br> |
| <!ELEMENT monthContext ( alias | (default*, monthWidth*, |
| special*)) ><br> |
| <!ATTLIST monthContext type ( format | stand-alone ) |
| #REQUIRED ><br> |
| <!ELEMENT monthWidth ( alias | (month*, special*)) ><br> |
| <!ATTLIST monthWidth type ( abbreviated| narrow | wide) |
| #REQUIRED ><br> |
| <!ELEMENT month ( #PCDATA )* ><br> |
| <!ATTLIST month type ( 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | |
| 10 | 11 | 12 | 13 ) #REQUIRED ><br> |
| <!ATTLIST month yeartype ( standard | leap ) #IMPLIED |
| ></p> |
| <p class="dtd"><!ELEMENT days ( alias | (dayContext*, |
| special*)) ><br> |
| <!ELEMENT dayContext ( alias | (default*, dayWidth*, |
| special*)) ><br> |
| <!ATTLIST dayContext type ( format | stand-alone ) #REQUIRED |
| ><br> |
| <!ELEMENT dayWidth ( alias | (day*, special*)) ><br> |
| <!ATTLIST dayWidth type NMTOKEN #REQUIRED ><br> |
| <!ELEMENT day ( #PCDATA ) ><br> |
| <!ATTLIST day type ( sun | mon | tue | wed | thu | fri | sat |
| ) #REQUIRED ></p> |
| <p class="dtd"><!ELEMENT quarters ( alias | |
| (quarterContext*, special*)) ><br> |
| <!ELEMENT quarterContext ( alias | (default*, quarterWidth*, |
| special*)) ><br> |
| <!ATTLIST quarterContext type ( format | stand-alone ) |
| #REQUIRED ><br> |
| <!ELEMENT quarterWidth ( alias | (quarter*, special*)) |
| ><br> |
| <!ATTLIST quarterWidth type NMTOKEN #REQUIRED ><br> |
| <!ELEMENT quarter ( #PCDATA ) ><br> |
| <!ATTLIST quarter type ( 1 | 2 | 3 | 4 ) #REQUIRED ></p> |
| <p class="dtd"><!ELEMENT eras (alias | (eraNames?, eraAbbr?, |
| eraNarrow?, special*)) ><br> |
| <!ELEMENT eraNames ( alias | (era*, special*) ) ><br> |
| <!ELEMENT eraAbbr ( alias | (era*, special*) ) ><br> |
| <!ELEMENT eraNarrow ( alias | (era*, special*) ) |
| ><br></p> |
| <p>The month and quarter names are identified numerically, |
| starting at 1. The weekday names are identified with short |
| strings, since there is no universally-accepted numeric |
| designation.</p> |
| <p>Month, day, and quarter names may vary along two axes: the |
| width and the context.</p> |
| <p>The context is either <i>format</i> (the default), the form |
| used within a complete date format string (such as "Saturday, |
| November 12", or <i>stand-alone</i>, the form for date elements |
| used independently, such as in calendar headers. The most |
| important distinction between format and stand-alone forms is a |
| grammatical distinction, for languages that require it. For |
| example, many languages require that a month name without an |
| associated day number (i.e. an independent form) be in the |
| basic <i>nominative</i> form, while a month name with an |
| associated day number (as in a complete date format) should be |
| in a different grammatical form: <i>genitive</i>, |
| <i>partitive</i>, etc. In past versions of CLDR, the |
| distinction between format and stand-alone forms was also used |
| to control capitalization (with stand-alone forms using |
| titlecase); however, this can be controlled separately and more |
| precisely using the <contextTransforms> element as |
| described in <i><a href= |
| "tr35-general.html#Context_Transform_Elements">ContextTransform |
| Elements</a></i>, so stand-alone forms should generally use |
| middle-of-sentence capitalization. However, if in a given |
| language, certain context/width combinations are always used in |
| a titlecase form — for example, stand-alone narrow forms for |
| months or weekdays — then these should be provided in that |
| form.</p> |
| <p>The width can be <i>wide</i> (the default), |
| <i>abbreviated</i>, or <i>narrow</i>; for days only, the width |
| can also be <i>short,</i> which is ideally between the |
| abbreviated and narrow widths, but must be no longer than |
| abbreviated and no shorter than narrow (if short day names are |
| not explicitly specified, abbreviated day names are used |
| instead). Note that for <monthPattern>, described in the |
| next section:</p> |
| <ul> |
| <li>There is an additional context type <i>numeric</i></li> |
| <li>When the context type is numeric, the width has a special |
| type <i>all</i></li> |
| </ul> |
| <p>The format values must be distinct for the wide, |
| abbreviated, and short widths. However, values for the narrow |
| width in either format or stand-alone contexts, as well as |
| values for other widths in stand-alone contexts, need not be |
| distinct; they might only be distinguished by context. For |
| example, "S" may be used both for Saturday and for Sunday. The |
| narrow width is typically used in calendar headers; it must be |
| the shortest possible width, no more than one character (or |
| grapheme cluster, or exemplar set element) in stand-alone |
| values (not including punctuation), and the shortest possible |
| widths (in terms of grapheme clusters) in format values. The |
| short width (if present) is often the shortest unambiguous |
| form.</p> |
| <p>Era names should be distinct within each of the widths, |
| including narrow; there is less disambiguating information for |
| them, and they are more likely to be used in a format that |
| requires parsing.</p> |
| <p>Due to aliases in root, the forms inherit "sideways". (See |
| <i><a href="tr35.html#Multiple_Inheritance">Multiple |
| Inheritance</a></i>.) For example, if the abbreviated format |
| data for Gregorian does not exist in a language X (in the chain |
| up to root), then it inherits from the wide format data in that |
| same language X.</p> |
| <pre id="line369"><monthContext type="format"> |
| <monthWidth type="abbreviated"> |
| <alias source="locale" path="../monthWidth[@type='wide']"/> |
| </monthWidth> |
| <monthWidth type="narrow"> |
| <alias source="locale" path="../../monthContext[@type='<b>stand-alone</b>']/monthWidth[@type='narrow']"/> |
| </monthWidth> |
| <monthWidth type="wide"> |
| <month type="1">1</month> |
| ... |
| <month type="12">12</month> |
| </monthWidth> |
| </monthContext> |
| <monthContext type="stand-alone"> |
| <monthWidth type="abbreviated"> |
| <alias source="locale" path="../../monthContext[@type='<b>format</b>']/monthWidth[@type='abbreviated']"/> |
| </monthWidth> |
| <monthWidth type="narrow"> |
| <month type="1">1</month> |
| ... |
| <month type="12">12</month> |
| </monthWidth> |
| <monthWidth type="wide"> |
| <alias source="locale" path="../../monthContext[@type='<b>format</b>']/monthWidth[@type='wide']"/> |
| </monthWidth> |
| </monthContext></pre> |
| <p>The yeartype attribute for months is used to distinguish |
| alternate month names that would be displayed for certain |
| calendars during leap years. The practical example of this |
| usage occurs in the Hebrew calendar, where the 7th month "Adar" |
| occurs in non-leap years, with the 6th month being skipped, but |
| in leap years there are two months named "Adar I" and "Adar |
| II". There are currently only two defined year types, standard |
| (the implied default) and leap.</p> |
| <p>For era elements, an additional alt="variant" form may be |
| supplied. This is primarily intended for use in the "gregorian" |
| calendar, with which two parallel sets of era designations are |
| used in some locales: one set with a religious reference (e.g. |
| English BC/AD), and one set without (e.g. English BCE/CE). The |
| most commonly-used set for the locale should be provided as the |
| default, and the other set may be provided as the alt="variant" |
| forms. See the example below.</p> |
| <p class="example">Example:</p> |
| <pre> <calendar type="<span style= |
| "color: blue">gregorian</span>"> |
| <months> |
| <monthContext type="<span style= |
| "color: blue">format</span>"> |
| <monthWidth type="<span style= |
| "color: blue">wide</span>"> |
| <month type="<span style= |
| "color: blue">1</span>"><span style= |
| "color: blue">January</span></month> |
| <month type="<span style= |
| "color: blue">2</span>"><span style= |
| "color: blue">February</span></month> |
| ... |
| <month type="<span style= |
| "color: blue">11</span>"><span style= |
| "color: blue">November</span></month> |
| <month type="<span style= |
| "color: blue">12</span>"><span style= |
| "color: blue">December</span></month> |
| </monthWidth> |
| <monthWidth type="<span style= |
| "color: blue">abbreviated</span>"> |
| <month type="<span style= |
| "color: blue">1</span>"><span style= |
| "color: blue">Jan</span></month> |
| <month type="<span style= |
| "color: blue">2</span>"><span style= |
| "color: blue">Feb</span></month> |
| ... |
| <month type="<span style= |
| "color: blue">11</span>"><span style= |
| "color: blue">Nov</span></month> |
| <month type="<span style= |
| "color: blue">12</span>"><span style= |
| "color: blue">Dec</span></month> |
| </monthWidth> |
| <monthContext type="<span style= |
| "color: blue">stand-alone</span>"> |
| <default type="<span style= |
| "color: blue">wide</span>"/> |
| <monthWidth type="<span style= |
| "color: blue">wide</span>"> |
| <month type="<span style= |
| "color: blue">1</span>"><span style= |
| "color: blue">Januaria</span></month> |
| <month type="<span style= |
| "color: blue">2</span>"><span style= |
| "color: blue">Februaria</span></month> |
| ... |
| <month type="<span style= |
| "color: blue">11</span>"><span style= |
| "color: blue">Novembria</span></month> |
| <month type="<span style= |
| "color: blue">12</span>"><span style= |
| "color: blue">Decembria</span></month> |
| </monthWidth> |
| <monthWidth type="<span style= |
| "color: blue">narrow</span>"> |
| <month type="<span style= |
| "color: blue">1</span>"><span style= |
| "color: blue">J</span></month> |
| <month type="<span style= |
| "color: blue">2</span>"><span style= |
| "color: blue">F</span></month> |
| ... |
| <month type="<span style= |
| "color: blue">11</span>"><span style= |
| "color: blue">N</span></month> |
| <month type="<span style= |
| "color: blue">12</span>"><span style= |
| "color: blue">D</span></month> |
| </monthWidth> |
| </monthContext> |
| </months> |
| |
| <days> |
| <dayContext type="<span style= |
| "color: blue">format</span>"> |
| <dayWidth type="<span style= |
| "color: blue">wide</span>"> |
| <day type="<span style= |
| "color: blue">sun</span>"><span style= |
| "color: blue">Sunday</span></day> |
| <day type="<span style= |
| "color: blue">mon</span>"><span style= |
| "color: blue">Monday</span></day> |
| ... |
| <day type="<span style= |
| "color: blue">fri</span>"><span style= |
| "color: blue">Friday</span></day> |
| <day type="<span style= |
| "color: blue">sat</span>"><span style= |
| "color: blue">Saturday</span></day> |
| </dayWidth> |
| <dayWidth type="<span style= |
| "color: blue">abbreviated</span>"> |
| <day type="<span style= |
| "color: blue">sun</span>"><span style= |
| "color: blue">Sun</span></day> |
| <day type="<span style= |
| "color: blue">mon</span>"><span style= |
| "color: blue">Mon</span></day> |
| ... |
| <day type="<span style= |
| "color: blue">fri</span>"><span style= |
| "color: blue">Fri</span></day> |
| <day type="<span style= |
| "color: blue">sat</span>"><span style= |
| "color: blue">Sat</span></day> |
| </dayWidth> |
| <dayWidth type="<span style= |
| "color: blue">narrow</span>"> |
| <day type="<span style= |
| "color: blue">sun</span>"><span style= |
| "color: blue">Su</span></day> |
| <day type="<span style= |
| "color: blue">mon</span>"><span style= |
| "color: blue">M</span></day> |
| ... |
| <day type="<span style= |
| "color: blue">fri</span>"><span style= |
| "color: blue">F</span></day> |
| <day type="<span style= |
| "color: blue">sat</span>"><span style= |
| "color: blue">Sa</span></day> |
| </dayWidth> |
| </dayContext> |
| <dayContext type="<span style= |
| "color: blue">stand-alone</span>"> |
| <dayWidth type="<span style= |
| "color: blue">narrow</span>"> |
| <day type="<span style= |
| "color: blue">sun</span>"><span style= |
| "color: blue">S</span></day> |
| <day type="<span style= |
| "color: blue">mon</span>"><span style= |
| "color: blue">M</span></day> |
| ... |
| <day type="<span style= |
| "color: blue">fri</span>"><span style= |
| "color: blue">F</span></day> |
| <day type="<span style= |
| "color: blue">sat</span>"><span style= |
| "color: blue">S</span></day> |
| </dayWidth> |
| </dayContext> |
| </days> |
| |
| <quarters> |
| <quarterContext type="<span style= |
| "color: blue">format</span>"> |
| <quarterWidth type="<span style= |
| "color: blue">abbreviated</span>"> |
| <quarter type="<span style= |
| "color: blue">1</span>"><span style= |
| "color: blue">Q1</span></quarter> |
| <quarter type="<span style= |
| "color: blue">2</span>"><span style= |
| "color: blue">Q2</span></quarter> |
| <quarter type="<span style= |
| "color: blue">3</span>"><span style= |
| "color: blue">Q3</span></quarter> |
| <quarter type="<span style= |
| "color: blue">4</span>"><span style= |
| "color: blue">Q4</span></quarter> |
| </quarterWidth> |
| <quarterWidth type="<span style= |
| "color: blue">wide</span>"> |
| <quarter type="<span style= |
| "color: blue">1</span>"><span style= |
| "color: blue">1st quarter</span></quarter> |
| <quarter type="<span style= |
| "color: blue">2</span>"><span style= |
| "color: blue">2nd quarter</span></quarter> |
| <quarter type="<span style= |
| "color: blue">3</span>"><span style= |
| "color: blue">3rd quarter</span></quarter> |
| <quarter type="<span style= |
| "color: blue">4</span>"><span style= |
| "color: blue">4th quarter</span></quarter> |
| </quarterWidth> |
| </quarterContext> |
| </quarters> |
| |
| <eras> |
| <eraAbbr> |
| <era type="<span style= |
| "color: blue">0</span>"><span style= |
| "color: blue">BC</span></era> |
| <era type="<span style= |
| "color: blue">0</span>" alt="<span style= |
| "color: blue">variant</span>"><span style= |
| "color: blue">BCE</span></era> |
| <era type="<span style= |
| "color: blue">1</span>"><span style= |
| "color: blue">AD</span></era> |
| <era type="<span style= |
| "color: blue">1</span>" alt="<span style= |
| "color: blue">variant</span>"><span style= |
| "color: blue">CE</span></era> |
| </eraAbbr> |
| <eraNames> |
| <era type="<span style= |
| "color: blue">0</span>"><span style= |
| "color: blue">Before Christ</span></era> |
| <era type="<span style= |
| "color: blue">0</span>" alt="<span style= |
| "color: blue">variant</span>"><span style= |
| "color: blue">Before Common Era</span></era> |
| <era type="<span style= |
| "color: blue">1</span>"><span style= |
| "color: blue">Anno Domini</span></era> |
| <era type="<span style= |
| "color: blue">1</span>" alt="<span style= |
| "color: blue">variant</span>"><span style= |
| "color: blue">Common Era</span></era> |
| </eraNames> |
| <eraNarrow> |
| <era type="<span style= |
| "color: blue">0</span>"><span style= |
| "color: blue">B</span></era> |
| <era type="<span style= |
| "color: blue">1</span>"><span style= |
| "color: blue">A</span></era> |
| </eraNarrow> |
| </eras> |
| </pre> |
| <h3>2.2 <a name="monthPatterns_cyclicNameSets" href= |
| "#monthPatterns_cyclicNameSets" id= |
| "monthPatterns_cyclicNameSets">Elements monthPatterns, |
| cyclicNameSets</a></h3> |
| <p class="dtd"><!ELEMENT monthPatterns ( alias | |
| (monthPatternContext*, special*)) ><br> |
| <!ELEMENT monthPatternContext ( alias | (monthPatternWidth*, |
| special*)) ><br> |
| <!ATTLIST monthPatternContext type ( format | stand-alone | |
| numeric ) #REQUIRED ><br> |
| <!ELEMENT monthPatternWidth ( alias | (monthPattern*, |
| special*)) ><br> |
| <!ATTLIST monthPatternWidth type ( abbreviated| narrow | |
| wide | all ) #REQUIRED ><br> |
| <!ELEMENT monthPattern ( #PCDATA ) ><br> |
| <!ATTLIST monthPattern type ( leap | standardAfterLeap | |
| combined ) #REQUIRED ><br></p> |
| <p class="dtd"><!ELEMENT cyclicNameSets ( alias | |
| (cyclicNameSet*, special*)) ><br> |
| <!ELEMENT cyclicNameSet ( alias | (cyclicNameContext*, |
| special*)) ><br> |
| <!ATTLIST cyclicNameSet type ( years | months | days | |
| dayParts | zodiacs | solarTerms ) #REQUIRED ><br> |
| <!ELEMENT cyclicNameContext ( alias | (cyclicNameWidth*, |
| special*)) ><br> |
| <!ATTLIST cyclicNameContext type ( format | stand-alone ) |
| #REQUIRED ><br> |
| <!ELEMENT cyclicNameWidth ( alias | (cyclicName*, special*)) |
| ><br> |
| <!ATTLIST cyclicNameWidth type ( abbreviated | narrow | wide |
| ) #REQUIRED ><br> |
| <!ELEMENT cyclicName ( #PCDATA ) ><br> |
| <!ATTLIST cyclicName type NMTOKEN #REQUIRED ><br></p> |
| <p>The Chinese lunar calendar can insert a leap month after |
| nearly any month of its year; when this happens, the month |
| takes the name of the preceding month plus a special marker. |
| The Hindu lunar calendars can insert a leap month before any |
| one or two months of the year; when this happens, not only does |
| the leap month take the name of the following month plus a |
| special marker, the following month also takes a special |
| marker. Moreover, in the Hindu calendar sometimes a month is |
| skipped, in which case the preceding month takes a special |
| marker plus the names of both months. The <monthPatterns> |
| element structure supports these special kinds of month names. |
| It parallels the <months> element structure, with various |
| contexts and widths, but with some differences:</p> |
| <ul> |
| <li>Since the month markers may be applied to numeric months |
| as well, there is an additional monthPatternContext type |
| "numeric" for this case. When the numeric context is used, |
| there is no need for different widths, so the |
| monthPatternWidth type is "all" for this case.</li> |
| <li>The monthPattern element itself is a pattern showing how |
| to create the modified month name from the standard month |
| name(s). The three types of possible pattern are for "leap", |
| "standardAfterLeap", and "combined".</li> |
| <li>The <monthPatterns> element is not present for |
| calendars that do not need it.</li> |
| </ul> |
| <p>The Chinese and Hindu lunar calendars also use a 60-name |
| cycle for designating years. The Chinese lunar calendars can |
| also use that cycle for months and days, and can use 12-name |
| cycles for designating day subdivisions or zodiac names |
| associated with years; a 24-name cycle of solar terms (12 pairs |
| of minor and major terms) is used to mark intervals in the |
| solar cycle. The <cyclicNameSets> element structure |
| supports these special kinds of name cycles; a cyclicNameSet |
| can be provided for types "year", "month", "day", "dayParts", |
| or "zodiacs". For each cyclicNameSet, there is a context and |
| width structure similar to that for day names. For a given |
| context and width, a set of cyclicName elements provides the |
| actual names.</p> |
| <p>Example:</p> |
| <pre> |
| <monthPatterns> |
| <monthPatternContext type="format"> |
| <monthPatternWidth type="wide"> |
| <monthPattern type="leap">闰{0}</monthPattern> |
| </monthPatternWidth> |
| </monthPatternContext> |
| <monthPatternContext type="stand-alone"> |
| <monthPatternWidth type="narrow"> |
| <monthPattern type="leap">闰{0}</monthPattern> |
| </monthPatternWidth> |
| </monthPatternContext> |
| <monthPatternContext type="numeric"> |
| <monthPatternWidth type="all"> |
| <monthPattern type="leap">闰{0}</monthPattern> |
| </monthPatternWidth> |
| </monthPatternContext> |
| </monthPatterns> |
| <cyclicNameSets> |
| <cyclicNameSet type="years"> |
| <cyclicNameContext type="format"> |
| <cyclicNameWidth type="abbreviated"> |
| <cyclicName type="1">甲子</cyclicName> |
| <cyclicName type="2">乙丑</cyclicName> |
| ... |
| <cyclicName type="59">壬戌</cyclicName> |
| <cyclicName type="60">癸亥</cyclicName> |
| </cyclicNameWidth> |
| </cyclicNameContext> |
| </cyclicNameSet> |
| <cyclicNameSet type="zodiacs"> |
| <cyclicNameContext type="format"> |
| <cyclicNameWidth type="abbreviated"> |
| <cyclicName type="1">鼠</cyclicName> |
| <cyclicName type="2">牛</cyclicName> |
| ... |
| <cyclicName type="11">狗</cyclicName> |
| <cyclicName type="12">猪</cyclicName> |
| </cyclicNameWidth> |
| </cyclicNameContext> |
| </cyclicNameSet> |
| <cyclicNameSet type="solarTerms"> |
| <cyclicNameContext type="format"> |
| <cyclicNameWidth type="abbreviated"> |
| <cyclicName type="1">立春</cyclicName> |
| <cyclicName type="2">雨水</cyclicName> |
| ... |
| <cyclicName type="23">小寒</cyclicName> |
| <cyclicName type="24">大寒</cyclicName> |
| </cyclicNameWidth> |
| </cyclicNameContext> |
| </cyclicNameSet> |
| </cyclicNameSets> |
| </pre> |
| <h3>2.3 <a name="dayPeriods" href="#dayPeriods" id= |
| "dayPeriods">Element dayPeriods</a></h3> |
| <p>The former am/pm elements have been deprecated, and replaced |
| by the more flexible dayPeriods.</p> |
| <p class="dtd"><!ELEMENT dayPeriods ( alias | |
| (dayPeriodContext*) ) ></p> |
| <p class="dtd"><!ELEMENT dayPeriodContext (alias | |
| dayPeriodWidth*) ><br> |
| <!ATTLIST dayPeriodContext type NMTOKEN #REQUIRED ></p> |
| <p class="dtd"><!ELEMENT dayPeriodWidth (alias | dayPeriod*) |
| ><br> |
| <!ATTLIST dayPeriodWidth type NMTOKEN #REQUIRED ></p> |
| <p class="dtd"><!ELEMENT dayPeriod ( #PCDATA ) ><br> |
| <!ATTLIST dayPeriod type NMTOKEN #REQUIRED ></p> |
| <p>These behave like months, days, and so on in terms of having |
| context and width. Each locale has an associated |
| dayPeriodRuleSet in the supplemental data, rules that specify |
| when the day periods start and end for that locale. Each type |
| in the rules needs to have a translation in a dayPeriod (but if |
| translation data is missing for a particular variable dayPeriod |
| in the locale’s language and script, formatting should fall |
| back to using the am/pm values). For more information, see |
| <em><a href="#Day_Period_Rules">Day Period Rules</a></em>.</p> |
| <p>The dayPeriod names should be distinct within each of the |
| context/width combinations, including narrow; as with era |
| names, there is less disambiguating information for them, and |
| they are more likely to be used in a format that requires |
| parsing. In some unambiguous cases, it is acceptable for |
| certain overlapping dayPeriods to be the same, such as the |
| names for "am" and "morning", or the names for "pm" and |
| "afternoon".</p> |
| <p class="example">Example:</p> |
| <pre> |
| <dayPeriods> |
| <dayPeriodContext type="format"> |
| <dayPeriodWidth type="wide"> |
| <dayPeriod type="am">AM</dayPeriod> |
| <dayPeriod type="noon">noon</dayPeriod> |
| <dayPeriod type="pm">PM</dayPeriod> |
| </dayPeriodWidth> |
| </dayPeriodContext> |
| </dayPeriods> |
| </pre> |
| <h3>2.4 <a name="dateFormats" href="#dateFormats" id= |
| "dateFormats">Element dateFormats</a></h3> |
| <p class="dtd"><!ELEMENT dateFormats (alias | (default*, |
| dateFormatLength*, special*)) ><br> |
| <!ELEMENT dateFormatLength (alias | (default*, dateFormat*, |
| special*)) ><br> |
| <!ATTLIST dateFormatLength type ( full | long | medium | |
| short ) #REQUIRED ><br> |
| <!ELEMENT dateFormat (alias | (pattern*, displayName*, |
| special*)) ></p> |
| <p>Standard date formats have the following form:</p> |
| <pre> <dateFormats> |
| <dateFormatLength type=”<span style= |
| "color: blue">full</span>”> |
| <dateFormat> |
| <pattern><span style= |
| "color: blue">EEEE, MMMM d, y</span></pattern> |
| </dateFormat> |
| </dateFormatLength> |
| <dateFormatLength type="<span style= |
| "color: blue">medium</span>"> |
| <dateFormat type="<span style= |
| "color: blue">DateFormatsKey2</span>"> |
| <pattern><span style= |
| "color: blue">MMM d, y</span></pattern> |
| </dateFormat> |
| </dateFormatLength> |
| <dateFormats></pre> |
| <p>The patterns for date formats and time formats are defined |
| in <i><a href="#Date_Format_Patterns">Date Format |
| Patterns</a>.</i> These patterns are intended primarily for |
| display of isolated date and time strings in user-interface |
| elements, rather than for date and time strings in the middle |
| of running text, so capitalization and grammatical form should |
| be chosen appropriately.</p> |
| <p>Standard date and time patterns are each normally provided |
| in four types: full (usually with weekday name), long (with |
| wide month name), medium, and short (usually with numeric |
| month).</p> |
| <h3>2.5 <a name="timeFormats" href="#timeFormats" id= |
| "timeFormats">Element timeFormats</a></h3> |
| <p class="dtd"><!ELEMENT timeFormats (alias | (default*, |
| timeFormatLength*, special*)) ><br> |
| <!ELEMENT timeFormatLength (alias | (default*, timeFormat*, |
| special*)) ><br> |
| <!ATTLIST timeFormatLength type ( full | long | medium | |
| short ) #REQUIRED ><br> |
| <!ELEMENT timeFormat (alias | (pattern*, displayName*, |
| special*)) ></p> |
| <p>Standard time formats have the following form:</p> |
| <pre> <timeFormats> |
| <timeFormatLength type=”<span style= |
| "color: blue">full</span>”> |
| <timeFormat> |
| <displayName><span style= |
| "color: blue">DIN 5008 (EN 28601)</span></displayName> |
| <pattern><span style= |
| "color: blue">h:mm:ss a z</span></pattern> |
| </timeFormat> |
| </timeFormatLength> |
| <timeFormatLength type="<span style= |
| "color: blue">medium</span>"> |
| <timeFormat> |
| <pattern><span style= |
| "color: blue">h:mm:ss a</span></pattern> |
| </timeFormat> |
| </timeFormatLength> |
| </timeFormats></pre> |
| <p>The preference of 12 hour versus 24 hour for the locale can |
| be derived from the <a href="#Time_Data">Time Data</a>. If the |
| preferred hour symbol is 'h' or 'K' |
| then the format is 12 hour; otherwise it is 24 hour. Formats |
| with 'h' or 'K' must also include a field with one of the day |
| period pattern characters: 'a', 'b', or 'B'.</p> |
| <p>To account for customary usage in some countries, APIs |
| should allow for formatting times that go beyond 23:59:59. For |
| example, in some countries it would be customary to indicate |
| that opening hours extending from <em>Friday at 7pm</em> to |
| <em>Saturday at 2am</em> in a format like the following:</p> |
| <p style="text-align: center">Friday: 19:00 – 26:00</p> |
| <p>Time formats use the specific non-location format (z or |
| zzzz) for the time zone name. This is the format that should be |
| used when formatting a specific time for presentation. When |
| formatting a time referring to a recurring time (such as a |
| meeting in a calendar), applications should substitute the |
| generic non-location format (v or vvvv) for the time zone in |
| the time format pattern. See <i><a href= |
| "#Using_Time_Zone_Names">Using Time Zone Names</a>.</i> for a |
| complete description of available time zone formats and their |
| uses.</p> |
| <h3>2.6 <a name="dateTimeFormats" href="#dateTimeFormats" id= |
| "dateTimeFormats">Element dateTimeFormats</a></h3> |
| <p class="dtd"><!ELEMENT dateTimeFormats (alias | (default*, |
| dateTimeFormatLength*, availableFormats*, appendItems*, |
| intervalFormats*, special*)) ><br></p> |
| <p>Date/Time formats have the following form:</p> |
| <pre> <dateTimeFormats> |
| <dateTimeFormatLength type=”<span style= |
| "color: blue">long</span>”> |
| <dateTimeFormat> |
| <pattern>{1} 'at' {0}</pattern> |
| </dateTimeFormat> |
| </dateTimeFormatLength> |
| <dateTimeFormatLength type=”<span style= |
| "color: blue">medium</span>”> |
| <dateTimeFormat> |
| <pattern>{1}, {0}</pattern> |
| </dateTimeFormat> |
| </dateTimeFormatLength> |
| <availableFormats> |
| <dateFormatItem id="Hm"><span style= |
| "color: blue">HH:mm</span></dateFormatItem> |
| <dateFormatItem id="Hms"><span style= |
| "color: blue">HH:mm:ss</span></dateFormatItem> |
| <dateFormatItem id="M"><span style= |
| "color: blue">L</span></dateFormatItem> |
| <dateFormatItem id="MEd"><span style= |
| "color: blue">E, M/d</span></dateFormatItem> |
| <dateFormatItem id="MMM"><span style= |
| "color: blue">LLL</span></dateFormatItem> |
| <dateFormatItem id="MMMEd"><span style= |
| "color: blue">E, MMM d</span></dateFormatItem> |
| <dateFormatItem id="MMMMEd"><span style= |
| "color: blue">E, MMMM d</span></dateFormatItem> |
| <dateFormatItem id="MMMMd"><span style= |
| "color: blue">MMMM d</span></dateFormatItem> |
| <dateFormatItem id="MMMd"><span style= |
| "color: blue">MMM d</span></dateFormatItem> |
| <dateFormatItem id="Md"><span style= |
| "color: blue">M/d</span></dateFormatItem> |
| <dateFormatItem id="d"><span style= |
| "color: blue">d</span></dateFormatItem> |
| <dateFormatItem id="hm"><span style= |
| "color: blue">h:mm a</span></dateFormatItem> |
| <dateFormatItem id="ms"><span style= |
| "color: blue">mm:ss</span></dateFormatItem> |
| <dateFormatItem id="y"><span style= |
| "color: blue">yyyy</span></dateFormatItem> |
| <dateFormatItem id="yM"><span style= |
| "color: blue">M/yyyy</span></dateFormatItem> |
| <dateFormatItem id="yMEd"><span style= |
| "color: blue">EEE, M/d/yyyy</span></dateFormatItem> |
| <dateFormatItem id="yMMM"><span style= |
| "color: blue">MMM yyyy</span></dateFormatItem> |
| <dateFormatItem id="yMMMEd"><span style= |
| "color: blue">EEE, MMM d, yyyy</span></dateFormatItem> |
| <dateFormatItem id="yMMMM"><span style= |
| "color: blue">MMMM yyyy</span></dateFormatItem> |
| <dateFormatItem id="yQ"><span style= |
| "color: blue">Q yyyy</span></dateFormatItem> |
| <dateFormatItem id="yQQQ"><span style= |
| "color: blue">QQQ yyyy</span></dateFormatItem> |
| . . . |
| </availableFormats> |
| <appendItems> |
| <appendItem request="<span style= |
| "color: blue">G</span>"><span style= |
| "color: blue">{0} {1}</span></appendItem> |
| <appendItem request="<span style= |
| "color: blue">w</span>"><span style= |
| "color: blue">{0} ({2}: {1})</span></appendItem> |
| . . . |
| </appendItems> |
| </dateTimeFormats></pre> |
| <pre> </calendar> |
| |
| <calendar type="<span style="color: blue">buddhist</span>"> |
| <eras> |
| <eraAbbr> |
| <era type="<span style= |
| "color: blue">0</span>"><span style= |
| "color: blue">BE</span></era> |
| </eraAbbr> |
| </eras> |
| </calendar></pre> |
| <p>These formats allow for date and time formats to be composed |
| in various ways.</p> |
| <h4>2.6.1 <a name="dateTimeFormat" href="#dateTimeFormat" id= |
| "dateTimeFormat">Element dateTimeFormat</a></h4> |
| <p class="dtd"><!ELEMENT dateTimeFormatLength (alias | |
| (default*, dateTimeFormat*, special*))><br> |
| <!ATTLIST dateTimeFormatLength type ( full | long | medium | |
| short ) #IMPLIED ><br> |
| <!ELEMENT dateTimeFormat (alias | (pattern*, displayName*, |
| special*))></p> |
| <p>The dateTimeFormat element works like the dateFormats and |
| timeFormats, except that the pattern is of the form "{1} {0}", |
| where {0} is replaced by the time format, and {1} is replaced |
| by the date format, with results such as "8/27/06 7:31 AM". |
| Except for the substitution markers {0} and {1}, text in the |
| dateTimeFormat is interpreted as part of a date/time pattern, |
| and is subject to the same rules described in <a href= |
| "#Date_Format_Patterns">Date Format Patterns</a>. This includes |
| the need to enclose ASCII letters in single quotes if they are |
| intended to represent literal text.</p> |
| <p>When combining a standard date pattern with a standard time |
| pattern, the type of dateTimeFormat used to combine them is |
| determined by the type of the date pattern. For example:</p> |
| <table cellspacing="0" cellpadding="4" border="1"> |
| <caption> |
| <a name="Date_Time_Combination_Examples" href= |
| "#Date_Time_Combination_Examples" id= |
| "Date_Time_Combination_Examples">Date-Time Combination |
| Examples</a> |
| </caption> |
| <tr> |
| <th>Date-Time Combination</th> |
| <th>dateTimeFormat</th> |
| <th>Results</th> |
| </tr> |
| <tr> |
| <td>full date + short time</td> |
| <td>full, e.g. "{1} 'at' {0}"</td> |
| <td>Wednesday, September 18, 2013 at 4:30 PM</td> |
| </tr> |
| <tr> |
| <td>medium date + long time</td> |
| <td>medium, e.g. "{1}, {0}"</td> |
| <td>Sep 18, 2013, 4:30:00 PM PDT</td> |
| </tr> |
| </table> |
| <h4>2.6.2 <a name="availableFormats_appendItems" href= |
| "#availableFormats_appendItems" id= |
| "availableFormats_appendItems">Elements availableFormats, |
| appendItems</a></h4> |
| <p class="dtd"><!ELEMENT availableFormats (alias | |
| (dateFormatItem*, special*))><br> |
| <!ELEMENT dateFormatItem ( #PCDATA ) ><br> |
| <!ATTLIST dateFormatItem id CDATA #REQUIRED ></p> |
| <p>The availableFormats element and its subelements provide a |
| more flexible formatting mechanism than the predefined list of |
| patterns represented by dateFormatLength, timeFormatLength, and |
| dateTimeFormatLength. Instead, there is an open-ended list of |
| patterns (represented by dateFormatItem elements as well as the |
| predefined patterns mentioned above) that can be matched |
| against a requested set of calendar fields and field lengths. |
| Software can look through the list and find the pattern that |
| best matches the original request, based on the desired |
| calendar fields and lengths. For example, the full month and |
| year may be needed for a calendar application; the request is |
| MMMMyyyy, but the best match may be "y MMMM" or even "G yy |
| MMMM", depending on the locale and calendar.</p> |
| <p>For some calendars, such as Japanese, a displayed year must |
| have an associated era, so for these calendars dateFormatItem |
| patterns with a year field should also include an era field. |
| When matching availableFormats patterns: If a client requests a |
| format string containing a year, and all the availableFormats |
| patterns with a year also contain an era, then include the era |
| as part of the result.</p> |
| <p>The id attribute is a so-called "skeleton", containing only |
| field information, and in a canonical order. Examples are |
| "yMMMM" for year + full month, or "MMMd" for abbreviated month |
| + day. In particular:</p> |
| <ul> |
| <li>The fields are from the <a href= |
| "#Date_Field_Symbol_Table">Date Field Symbol Table</a> in |
| <i><a href="#Date_Format_Patterns">Date Format |
| Patterns</a></i>.</li> |
| <li>The canonical order is from top to bottom in that table; |
| that is, "yM" not "My".</li> |
| <li>Only one field of each type is allowed; that is, "Hh" is |
| not valid.</li> |
| </ul> |
| <p>In order to support user overrides of default locale |
| behavior, data should be supplied for both 12-hour-cycle time |
| formats (using h or K) and 24-hour-cycle time formats (using H |
| or k), even if one of those styles is not commonly used; the |
| locale's actual preference for 12-hour or 24-hour time cycle is |
| determined from the <a |
| href="#Time_Data">Time Data</a> as described above in |
| <a href="#timeFormats">timeFormats</a>. Thus skeletons |
| using h or K should have patterns that only use h or K for |
| hours, while skeletons using H or k should have patterns that |
| only use H or k for hours.</p> |
| <p>The rules governing use of day period pattern characters in |
| patterns and skeletons are as follows:</p> |
| <ul> |
| <li>Patterns and skeletons for 24-hour-cycle time formats |
| (using H or k) currently <em>should not</em> include fields |
| with day period characters (a, b, or B); these pattern |
| characters should be ignored if they appear in skeletons. |
| However, in the future, CLDR may allow use of B (but not a or |
| b) in 24-hour-cycle time formats.</li> |
| <li>Patterns for 12-hour-cycle time formats (using h or K) |
| <em>must</em> include a day period field using one of a, b, |
| or B.</li> |
| <li>Skeletons for 12-hour-cycle time formats (using h or K) |
| <em>may</em> include a day period field using one of a, b, or |
| B. If they do not, the skeleton will be treated as implicitly |
| containing a.</li> |
| </ul> |
| <p>Locales should generally provide availableFormats data for a |
| fairly complete set of time skeletons without B, typically the |
| following:</p><code>H, h, Hm, hm, Hms, hms, Hmv, hmv, Hmsv, |
| hmsv</code> |
| <p>Locales that use 12-hour-cycle time formats with B may |
| provide availableFormats data for a smaller set of time |
| skeletons with B, for example:</p><code>Bh, Bhm, Bhms</code> |
| <p>When matching a requested skeleton containing b or B to the |
| skeletons actually available in the data, if there is no |
| skeleton matching the specified day period field, then find a |
| match in which the b or B matches an explicit or implicit 'a' |
| in the skeleton, but replace the 'a' in the corresponding |
| pattern with the requested day period b or B. The following |
| table illustrates how requested skeletons map to patterns with |
| different sets of availableFormats data:</p> |
| <table cellspacing="0" cellpadding="4" border="1"> |
| <caption> |
| <a name="Mapping_Requested_Time_Skeletons_To_Patterns" |
| href="#Mapping_Requested_Time_Skeletons_To_Patterns" id= |
| "Mapping_Requested_Time_Skeletons_To_Patterns">Mapping |
| Requested Time Skeletons To Patterns</a> |
| </caption> |
| <tr> |
| <th></th> |
| <th colspan="2">results for different availableFormats data |
| sets</th> |
| </tr> |
| <tr> |
| <th>requested skeleton</th> |
| <th>set 1:<br> |
| ...id="H">H</date...<br> |
| ...id="h">h a</date...</th> |
| <th>set 2:<br> |
| ...id="H">H</date...<br> |
| ...id="h">h a</date...<br> |
| ...id="Bh">B h</date...</th> |
| </tr> |
| <tr> |
| <td>"h" (or "ah")</td> |
| <td>"h a"</td> |
| <td>"h a"</td> |
| </tr> |
| <tr> |
| <td>"bh"</td> |
| <td>"h b"</td> |
| <td>"h b"</td> |
| </tr> |
| <tr> |
| <td>"Bh"</td> |
| <td>"h B"</td> |
| <td>"B h"</td> |
| </tr> |
| <tr> |
| <td>"H" (or "aH", "bH", "BH")</td> |
| <td>"H"</td> |
| <td>"H"</td> |
| </tr> |
| </table><br> |
| <p>The hour input skeleton symbols 'j', 'J', and 'C' can be |
| used to select the best hour format (h, H, …) before |
| processing, and the appropriate dayperiod format (a, b, B) |
| after a successful match that contains an 'a' symbol.</p> |
| <p>The dateFormatItems inherit from their parent locale, so the |
| inherited items need to be considered when processing.</p> |
| <h5><a name="Matching_Skeletons" href="#Matching_Skeletons" id= |
| "Matching_Skeletons">2.6.2.1 Matching Skeletons</a></h5> |
| <p>It is not necessary to supply dateFormatItems with skeletons |
| for every field length; fields in the skeleton and pattern are |
| expected to be expanded in parallel to handle a request.</p> |
| <p>Typically a “best match” is found using a closest distance |
| match, such as:</p> |
| <ol> |
| <li>Symbols requesting a best choice for the locale are |
| replaced. |
| <ul> |
| <li>j → one of {H, k, h, K}; C → one of {a, b, B}</li> |
| </ul> |
| </li> |
| <li>For fields with symbols representing the same type (year, |
| month, day, etc): |
| <ol> |
| <li>Most symbols have a small distance from each other. |
| <ul> |
| <li>M ≅ L; E ≅ c; a ≅ b ≅ B; H ≅ k ≅ h ≅ K; ...</li> |
| </ul> |
| </li> |
| <li>Width differences among fields, other than those |
| marking text vs numeric, are given small distance from |
| each other. |
| <ul> |
| <li>MMM ≅ MMMM</li> |
| <li>MM ≅ M</li> |
| </ul> |
| </li> |
| <li>Numeric and text fields are given a larger distance |
| from each other. |
| <ul> |
| <li>MMM ≈ MM</li> |
| </ul> |
| </li> |
| <li>Symbols representing substantial differences (week of |
| year vs week of month) are given much larger a distances |
| from each other. |
| <ul> |
| <li>d ≋ D; ...</li> |
| </ul> |
| </li> |
| </ol> |
| </li> |
| <li>A requested skeleton that includes both seconds and |
| fractional seconds (e.g. “mmssSSS”) is allowed to match a |
| dateFormatItem skeleton that includes seconds but not |
| fractional seconds (e.g. “ms”). In this case the requested |
| sequence of ‘S’ characters (or its length) should be retained |
| separately and used when adjusting the pattern, as described |
| below.</li> |
| <li>Otherwise, missing or extra fields cause a match to fail. |
| (But see <strong><a href="#Missing_Skeleton_Fields">Missing |
| Skeleton Fields</a></strong> below).</li> |
| </ol> |
| <p>Once a skeleton match is found, the corresponding pattern is |
| used, but with adjustments. Consider the following |
| dateFormatItem:</p> |
| <pre> <dateFormatItem id="yMMMd"><span style= |
| "color: blue">d MMM y</span></dateFormatItem> |
| </pre> |
| <p>If this is the best match for yMMMMd, pattern is |
| automatically expanded to produce the pattern |
| "d MMMM y" in response to the request. Of course, if |
| the desired behavior is that a request for yMMMMd should |
| produce something <i>other</i> than "d MMMM y", a |
| separate dateFormatItem must be present, for example:</p> |
| <pre> <dateFormatItem id="yMMMMd"><span style= |
| "color: blue">d 'de' MMMM 'de' y</span></dateFormatItem></pre> |
| <p>However, such automatic expansions should never convert a |
| numeric element in the pattern to an alphabetic element. |
| Consider the following dateFormatItem:</p> |
| <pre> |
| <dateFormatItem id="yMMM">y年M月</dateFormatItem></pre> |
| <p>If this is the best match for a requested skeleton yMMMM, |
| automatic expansion should not produce a corresponding pattern |
| “y年MMMM月”; rather, since “y年M月” specifies a numeric month M, |
| automatic expansion should not modify the pattern, and should |
| produce “y年M月” as the match for requested skeleton yMMMM.</p> |
| <p>If the requested skeleton included both seconds and |
| fractional seconds and the dateFormatItem skeleton included |
| seconds but not fractional seconds, then the seconds field of |
| the corresponding pattern should be adjusted by appending the |
| locale’s decimal separator, followed by the sequence of ‘S’ |
| characters from the requested skeleton.</p> |
| <h5><a name="Missing_Skeleton_Fields" href= |
| "#Missing_Skeleton_Fields" id="Missing_Skeleton_Fields">2.6.2.2 |
| Missing Skeleton Fields</a></h5> |
| <p>If a client-requested set of fields includes both date and |
| time fields, and if the availableFormats data does not include |
| a dateFormatItem whose skeleton matches the same set of fields, |
| then the request should be handled as follows:</p> |
| <ol> |
| <li>Divide the request into a date fields part and a time |
| fields part.</li> |
| <li>For each part, find the matching dateFormatItem, and |
| expand the pattern as above.</li> |
| <li>Combine the patterns for the two dateFormatItems using |
| the appropriate dateTimeFormat pattern, determined as follows |
| from the requested date fields: |
| <ul> |
| <li>If the requested date fields include wide month |
| (MMMM, LLLL) and weekday name of any length (e.g. E, |
| EEEE, c, cccc), use |
| <dateTimeFormatLength type="full"></li> |
| <li>Otherwise, if the requested date fields include wide |
| month, use |
| <dateTimeFormatLength type="long"></li> |
| <li>Otherwise, if the requested date fields include |
| abbreviated month (MMM, LLL), use |
| <dateTimeFormatLength type="medium"></li> |
| <li>Otherwise use <dateTimeFormatLength |
| type="short"></li> |
| </ul> |
| </li> |
| </ol> |
| <p class="dtd"><!ELEMENT appendItems (alias | (appendItem*, |
| special*))><br> |
| <!ELEMENT appendItem ( #PCDATA ) ><br> |
| <!ATTLIST appendItem request CDATA ></p> |
| <p>In case the best match does not include all the requested |
| calendar fields, the appendItems element describes how to |
| append needed fields to one of the existing formats. Each |
| appendItem element covers a single calendar field. In the |
| pattern, {0} represents the format string, {1} the data content |
| of the field, and {2} the display name of the field (see |
| <a href="#Calendar_Fields">Calendar Fields</a>).</p> |
| <h4>2.6.3 <a name="intervalFormats" href="#intervalFormats" id= |
| "intervalFormats">Element intervalFormats</a></h4> |
| <p class="dtd"><!ELEMENT intervalFormats (alias | |
| (intervalFormatFallback*, intervalFormatItem*, special*)) |
| ></p> |
| <p class="dtd"><!ELEMENT intervalFormatFallback ( #PCDATA ) |
| ></p> |
| <p class="dtd"><!ELEMENT intervalFormatItem (alias | |
| (greatestDifference*, special*)) ><br> |
| <!ATTLIST intervalFormatItem id NMTOKEN #REQUIRED ></p> |
| <p class="dtd"><!ELEMENT greatestDifference ( #PCDATA ) |
| ><br> |
| <!ATTLIST greatestDifference id NMTOKEN #REQUIRED ></p> |
| <p>Interval formats allow for software to format intervals like |
| "Jan 10-12, 2008" as a shorter and more natural format than |
| "Jan 10, 2008 - Jan 12, 2008". They are designed to take a |
| "skeleton" pattern (like the one used in availableFormats) plus |
| start and end datetime, and use that information to produce a |
| localized format.</p> |
| <p>The data supplied in CLDR requires the software to determine |
| the calendar field with the greatest difference before using |
| the format pattern. For example, the greatest difference in |
| "Jan 10-12, 2008" is the day field, while the greatest |
| difference in "Jan 10 - Feb 12, 2008" is the month field. This |
| is used to pick the exact pattern. The pattern is then designed |
| to be broken up into two pieces by determining the first |
| repeating field. For example, "MMM d-d, y" would be broken up |
| into "MMM d-" and "d, y". The two parts are formatted with the |
| first and second datetime, as described in more detail |
| below.</p> |
| <p>In case there is no matching pattern, the |
| intervalFormatFallback defines the fallback pattern. The |
| fallback pattern is of the form "{0} - {1}" or "{1} - {0}", |
| where {0} is replaced by the start datetime, and {1} is |
| replaced by the end datetime. The fallback pattern determines |
| the default order of the interval pattern. "{0} - {1}" means |
| the first part of the interval patterns in current local are |
| formatted with the start datetime, while "{1} - {0}" means the |
| first part of the interval patterns in current locale are |
| formatted with the end datetime.</p> |
| <p>The id attribute of intervalFormatItem is the "skeleton" |
| pattern (like the one used in availableFormats) on which the |
| format pattern is based. The id attribute of greatestDifference |
| is the calendar field letter, for example 'M', which is the |
| greatest difference between start and end datetime.</p> |
| <p>The greatest difference defines a specific interval pattern |
| of start and end datetime on a "skeleton" and a |
| greatestDifference. As stated above, the interval pattern is |
| designed to be broken up into two pieces. Each piece is similar |
| to the pattern defined in date format. Also, each interval |
| pattern could override the default order defined in fallback |
| pattern. If an interval pattern starts with "latestFirst:", the |
| first part of this particular interval pattern is formatted |
| with the end datetime. If an interval pattern starts with |
| "earliestFirst:", the first part of this particular interval |
| pattern is formatted with the start datetime. Otherwise, the |
| order is the same as the order defined in |
| intervalFormatFallback.</p> |
| <p>For example, the English rules that produce "Jan 10–12, |
| 2008", "Jan 10 – Feb 12, 2008", and "Jan 10, 2008 – Feb. 12, |
| 2009" are as follows:</p> |
| <p class="example"><intervalFormatItem id="yMMMd"><br> |
| <greatestDifference id="M">MMM d – MMM d, |
| yyyy</greatestDifference><br> |
| <greatestDifference id="d">MMM d–d, |
| yyyy</greatestDifference><br> |
| <greatestDifference id="y">MMM d, yyyy – MMM d, |
| yyyy</greatestDifference><br> |
| </intervalFormatItem></p> |
| <p>To format a start and end datetime, given a particular |
| "skeleton":</p> |
| <ol> |
| <li>Look for the intervalFormatItem element that matches the |
| "skeleton", starting in the current locale and then following |
| the locale fallback chain up to, but not including root |
| (better results are obtained by following steps 2-6 below |
| with locale- or language- specific data than by using |
| matching intervalFormats from root).</li> |
| <li>If no match was found from the previous step, check what |
| the closest match is in the fallback locale chain, as in |
| availableFormats. That is, this allows for adjusting the |
| string value field's width, including adjusting between "MMM" |
| and "MMMM", and using different variants of the same field, |
| such as 'v' and 'z'.</li> |
| <li>If no match was found from the previous steps and the |
| skeleton combines date fields such as y,M,d with time fields |
| such as H,h,m,s, then an intervalFormatItem can be |
| synthesized as follows: |
| <ol> |
| <li>For greatestDifference values corresponding to the |
| date fields in the skeleton, use the mechanisms described |
| under <a href= |
| "#availableFormats_appendItems">availableFormats</a> to |
| generate the complete date-time pattern corresponding to |
| the skeleton, and then combine two such patterns using |
| the intervalFormatFallback pattern (the result will be |
| the same for each greatestDifference of a day or longer). |
| For example:<br> |
| MMMdHm/d → "MMM d 'at' H:mm – MMM d 'at' H:mm" → "Jan 3 |
| at 9:00 – Jan 6 at 11:00"</li> |
| <li>For greatestDifference values corresponding to the |
| time fields in the skeleton, separate the skeleton into a |
| date fields part and a time fields part. Use the |
| mechanisms described under availableFormats to generate a |
| date pattern corresponding to the date fields part. Use |
| the time fields part to look up an intervalFormatItem. |
| For each greatestDifferent in the intervalFormatItem, |
| generate a pattern by using the <a href= |
| "#dateTimeFormat">dateTimeFormat</a> to combine the date |
| pattern with the intervalFormatItem’s greatestDifference |
| element value. For example:<br> |
| MMMdHm/H → "MMM d 'at' H:mm – H:mm" → "Jan 3 at 9:00 – |
| 11:00"</li> |
| </ol> |
| </li> |
| <li>If a match is found from previous steps, compute the |
| calendar field with the greatest difference between start and |
| end datetime. If there is no difference among any of the |
| fields in the pattern, format as a single date using |
| availableFormats, and return.</li> |
| <li>Otherwise, look for greatestDifference element that |
| matches this particular greatest difference.</li> |
| <li>If there is a match, use the pieces of the corresponding |
| pattern to format the start and end datetime, as above.</li> |
| <li>Otherwise, format the start and end datetime using the |
| fallback pattern.</li> |
| </ol> |
| <h2>3 <a name="Calendar_Fields" href="#Calendar_Fields" id= |
| "Calendar_Fields">Calendar Fields</a></h2> |
| <p class="dtd"><!ELEMENT fields ( alias | (field*, |
| special*)) ><br> |
| <!ELEMENT field ( alias | (displayName*, relative*, |
| relativeTime*, relativePeriod*, special*)) ><br> |
| <!ATTLIST field type ( era | era-short | era-narrow | year | |
| year-short | year-narrow | quarter | quarter-short | |
| quarter-narrow | month | month-short | month-narrow | week | |
| week-short | week-narrow | weekOfMonth | weekOfMonth-short | |
| weekOfMonth-narrow | day | day-short | day-narrow | dayOfYear | |
| dayOfYear-short | dayOfYear-narrow | weekday | weekday-short | |
| weekday-narrow | weekdayOfMonth | weekdayOfMonth-short | |
| weekdayOfMonth-narrow | sun | sun-short | sun-narrow | mon | |
| mon-short | mon-narrow | tue | tue-short | tue-narrow | wed | |
| wed-short | wed-narrow | thu | thu-short | thu-narrow | fri | |
| fri-short | fri-narrow | sat | sat-short | sat-narrow | |
| dayperiod | dayperiod-short | dayperiod-narrow | hour | |
| hour-short | hour-narrow | minute | minute-short | |
| minute-narrow | second | second-short | second-narrow | zone | |
| zone-short | zone-narrow ) #IMPLIED ></p> |
| <p class="dtd"><!ELEMENT relative (#PCDATA) ><br> |
| <!ATTLIST relative type NMTOKEN #IMPLIED ></p> |
| <p class="dtd"><!ELEMENT relativeTime ( alias | |
| (relativeTimePattern*, special*)) ><br> |
| <!ATTLIST relativeTime type NMTOKEN #REQUIRED ></p> |
| <p class="dtd"><!ELEMENT relativeTimePattern ( #PCDATA ) |
| ><br> |
| <!ATTLIST relativeTimePattern count ( zero | one | two | few |
| | many | other ) #REQUIRED ></p> |
| <p class="dtd"><!ELEMENT relativePeriod (#PCDATA) ></p> |
| <p>Translations may be supplied for names of calendar fields |
| (elements of a calendar, such as Day, Month, Year, Hour, and so |
| on), and for relative values for those fields (for example, the |
| day with relative value -1 is "Yesterday"). There are four |
| types of translations; some are only relevant or useful for |
| certain types of fields:</p> |
| <ul> |
| <li><displayName> General display name for the field |
| type. This should be relevant for all elements, including |
| those like era and zone that might not have useful forms for |
| the other name types. These are typically presented in |
| titlecase (eg “Day”) since they are intended as labels in a |
| UI.</li> |
| <li><relative> Display names for the current instance |
| of the field, and one or two past and future instances. In |
| English, data is provided for year, quarter, month, week, |
| day, specific days of the week (sun, mon, tue, …), and—with |
| offset 0 only—for hour, minute, and second.</li> |
| <li><relativeTime> Display names for an instance of the |
| field that is a counted number of units in the past or the |
| future relative to the current instance; this needs plural |
| forms. In English, data is provided for year, quarter, month, |
| week, day, specific days of the week, ,hour, minute, and |
| second.</li> |
| <li><relativePeriod> Pattern for designating an |
| instance of the specified field in relation to some other |
| date reference. This is currently only used for weeks, and |
| provides a pattern such as “the week of {0}” which can be |
| used to generate designations such as “the week of April 11, |
| 2016” or “the week of April 11–15”.</li> |
| </ul> |
| <p>Where there is not a convenient, customary word or phrase in |
| a particular language for a particular type of relative value, |
| it should be omitted.</p> |
| <p>Examples, first for English:</p> |
| <pre> <fields> |
| … |
| <field type="day"> |
| <displayName>Day</displayName> |
| <relative type="-1">yesterday</relative> |
| <relative type="0">today</relative> |
| <relative type="1">tomorrow</relative> |
| <relativeTime type="future"> |
| <relativeTimePattern count="one">in {0} day</relativeTimePattern> |
| <relativeTimePattern count="other">in {0} days</relativeTimePattern> |
| </relativeTime> |
| <relativeTime type="past"> |
| <relativeTimePattern count="one">{0} day ago</relativeTimePattern> |
| <relativeTimePattern count="other">{0} days ago</relativeTimePattern> |
| </relativeTime> |
| </field> |
| <field type="weekday"> |
| <displayName>Day of the Week</displayName> |
| </field> |
| <field type="sun"> |
| <relative type="-1">last Sunday</relative> |
| <relative type="0">this Sunday</relative> |
| <relative type="1">next Sunday</relative> |
| <relativeTime type="future"> |
| <relativeTimePattern count="one">in {0} Sunday</relativeTimePattern> |
| <relativeTimePattern count="other">in {0} Sundays</relativeTimePattern> |
| </relativeTime> |
| <relativeTime type="past"> |
| <relativeTimePattern count="one">{0} Sunday ago</relativeTimePattern> |
| <relativeTimePattern count="other">{0} Sundays ago</relativeTimePattern> |
| </relativeTime> |
| </field> |
| … |
| <field type="hour"> |
| <displayName>Hour</displayName> |
| <relative type="0">now</relative> |
| <relativeTime type="future"> |
| <relativeTimePattern count="one">in {0} hour</relativeTimePattern> |
| <relativeTimePattern count="other">in {0} hours</relativeTimePattern> |
| </relativeTime> |
| <relativeTime type="past"> |
| <relativeTimePattern count="one">{0} hour ago</relativeTimePattern> |
| <relativeTimePattern count="other">{0} hours ago</relativeTimePattern> |
| </relativeTime> |
| </field> |
| … |
| </fields> |
| </pre> |
| <p>Second, for German; includes relative type="-2"/"2", present |
| in the English example:</p> |
| <pre> <fields> |
| … |
| <field type="day"> |
| <displayName>Tag</displayName> |
| <relative type="-2">Vorgestern</relative> |
| <relative type="-1">Gestern</relative> |
| <relative type="0">Heute</relative> |
| <relative type="1">Morgen</relative> |
| <relative type="2">Übermorgen</relative> |
| <relativeTime type="future"> |
| <relativeTimePattern count="one">In {0} Tag</relativeTimePattern> |
| <relativeTimePattern count="other">In {0} Tagen</relativeTimePattern> |
| </relativeTime> |
| <relativeTime type="past"> |
| <relativeTimePattern count="one">Vor {0} Tag</relativeTimePattern> |
| <relativeTimePattern count="other">Vor {0} Tagen</relativeTimePattern> |
| </relativeTime> |
| </field> |
| … |
| </fields> |
| </pre> |
| <p>A special name for “now” is indicated using <relative |
| type="0"> for the "second" field. For example, in |
| English:</p> |
| <pre> <field type="second"> |
| <displayName>Second</displayName> |
| <relative type="0">now</relative> |
| … |
| </field></pre> |
| <p>Different widths can be supplied for certain fields, such |
| as:</p> |
| <pre> |
| <field type="<strong>year-short</strong>"><br> <displayName>yr.</displayName><br> <relative type="-1">last yr.</relative><br> <relative type="0">this yr.</relative><br> <relative type="1">next yr.</relative><br> <relativeTime type="future"><br> <relativeTimePattern count="one">in {0} yr.</relativeTimePattern><br> <relativeTimePattern count="other">in {0} yr.</relativeTimePattern><br> </relativeTime><br> <relativeTime type="past"><br> <relativeTimePattern count="one">{0} yr. ago</relativeTimePattern><br> <relativeTimePattern count="other">{0} yr. ago</relativeTimePattern><br> </relativeTime><br></field></pre> |
| <p>As in other cases, <strong>narrow</strong> may be ambiguous |
| out of context.</p> |
| <h2>4 <a name="Supplemental_Calendar_Data" href= |
| "#Supplemental_Calendar_Data" id= |
| "Supplemental_Calendar_Data">Supplemental Calendar |
| Data</a></h2> |
| <h3>4.1 <a name="Calendar_Data" href="#Calendar_Data" id= |
| "Calendar_Data">Calendar Data</a></h3> |
| <p class="dtd"><!ELEMENT calendarData ( calendar* )><br> |
| <!ELEMENT calendar ( calendarSystem?, eras? )><br> |
| <!ATTLIST calendar type NMTOKENS #REQUIRED><br> |
| <!ATTLIST calendar territories NMTOKENS #IMPLIED > |
| <!-- deprecated, replaced by calendarPreferenceData |
| --></p> |
| <p class="dtd"><!ELEMENT calendarSystem EMPTY><br> |
| <!ATTLIST calendarSystem type (solar | lunar | lunisolar | |
| other) #REQUIRED></p> |
| <p class="dtd"><!ELEMENT eras ( era* )></p> |
| <p class="dtd"><!ELEMENT era EMPTY><br> |
| <!ATTLIST era type NMTOKENS #REQUIRED><br> |
| <!ATTLIST era start CDATA #IMPLIED><br> |
| <!ATTLIST era end CDATA #IMPLIED></p> |
| <p>The <calendarData> element now provides only |
| locale-independent data about calendar behaviors via its |
| <calendar> subelements, which for each calendar can |
| specify the astronomical basis of the calendar (solar, lunar, |
| etc.) and the date ranges for its eras.</p> |
| <p>Era start or end dates are specified in terms of the |
| equivalent proleptic Gregorian date (in "y-M-d" format). Eras |
| may be open-ended, with unspecified start or end dates. For |
| example, here are the eras for the Gregorian calendar:</p> |
| <pre> <era type="0" end="0" /> |
| <era type="1" start="1" /> |
| </pre> |
| <p>For a sequence of eras with specified start dates, the end |
| of each era need not be explicitly specified (it is assumed to |
| match the start of the subsequent era). For example, here are |
| the first few eras for the Japanese calendar:</p> |
| <pre> <era type="0" start="645-6-19"/> |
| <era type="1" start="650-2-15"/> |
| <era type="2" start="672-1-1"/> |
| … |
| </pre> |
| <p><b>Note:</b> The territories attribute in the calendar |
| element is deprecated. It was formerly used to indicate |
| calendar preference by territory, but this is now given by the |
| <i><a href="#Calendar_Preference_Data">Calendar Preference |
| Data</a></i> below.</p> |
| <h3>4.2 <a name="Calendar_Preference_Data" href= |
| "#Calendar_Preference_Data" id= |
| "Calendar_Preference_Data">Calendar Preference Data</a></h3> |
| <p class="dtd"><!ELEMENT calendarPreferenceData ( |
| calendarPreference* ) ><br> |
| <!ELEMENT calendarPreference EMPTY ><br> |
| <!ATTLIST calendarPreference territories NMTOKENS #REQUIRED |
| ><br> |
| <!ATTLIST calendarPreference ordering NMTOKENS #REQUIRED |
| ></p> |
| <p>The calendarPreference element provides a list of commonly |
| used calendar types in a territory. The ordering attribute |
| indicates the list of calendar types in preferred order. The |
| first calendar type in the list is the default calendar type |
| for the territory. For example:</p> |
| <pre> |
| <calendarPreference territories="001" ordering="gregorian"/> |
| <calendarPreference territories="JP" ordering="gregorian japanese"/> |
| <calendarPreference territories="TH" ordering="buddhist gregorian"/> |
| </pre> |
| <p>The calendarPreference elements above indicate:</p> |
| <ul> |
| <li>The default (for territory "001") is that only the |
| Gregorian calendar is commonly used.</li> |
| <li>For Japan, the Gregorian and Japanese calendars are both |
| used, with Gregorian preferred (the default).</li> |
| <li>For Thailand, the Buddhist and Gregorian calendars are |
| both used, and Buddhist is preferred (the default).</li> |
| </ul> |
| <p>The calendars in common use for a locale should typically be |
| shown in UIs that provide a choice of calendars. (An 'Other...' |
| button could give access to the other available calendars.)</p> |
| <h3>4.3 <a name="Week_Data" href="#Week_Data" id= |
| "Week_Data">Week Data</a></h3> |
| <p class="dtd"><!ELEMENT weekData ( minDays*, firstDay*, |
| weekendStart*, weekendEnd*, weekOfPreference* )></p> |
| <p class="dtd"><!ELEMENT minDays EMPTY><br> |
| <!ATTLIST minDays count (1 | 2 | 3 | 4 | 5 | 6 | 7) |
| #REQUIRED><br> |
| <!ATTLIST minDays territories NMTOKENS #REQUIRED></p> |
| <p class="dtd"><!ELEMENT firstDay EMPTY ><br> |
| <!ATTLIST firstDay day (sun | mon | tue | wed | thu | fri | |
| sat) #REQUIRED><br> |
| <!ATTLIST firstDay territories NMTOKENS #REQUIRED></p> |
| <p class="dtd"><!ELEMENT weekendStart EMPTY><br> |
| <!ATTLIST weekendStart day (sun | mon | tue | wed | thu | |
| fri | sat) #REQUIRED><br> |
| <!ATTLIST weekendStart territories NMTOKENS |
| #REQUIRED></p> |
| <p class="dtd"><!ELEMENT weekendEnd EMPTY><br> |
| <!ATTLIST weekendEnd day (sun | mon | tue | wed | thu | fri |
| | sat) #REQUIRED><br> |
| <!ATTLIST weekendEnd territories NMTOKENS #REQUIRED></p> |
| <p class="dtd"><!ELEMENT weekOfPreference EMPTY><br> |
| <!ATTLIST weekOfPreference locales NMTOKENS |
| #REQUIRED><br> |
| <!ATTLIST weekOfPreference ordering NMTOKENS |
| #REQUIRED></p> |
| <p>These values provide territory-specific information needed |
| for week-of-year and week-of-month calculations, as well as |
| information on conventions for first day of the week, for |
| weekends, and for week designations. For most elements, the |
| default is provided by the element with territories="001"; for |
| weekOfPreference elements the default is provided by the |
| element with locales="und".</p> |
| <pre><weekData> |
| <minDays count="1" territories="001"/> |
| <minDays count="4" territories="AD AN AT AX BE BG CH CZ DE DK EE ES FI FJ FO FR GB …"/> |
| <firstDay day="mon" territories="001"/> |
| <firstDay day="fri" territories="BD MV"/> |
| <firstDay day="sat" territories="AE AF BH DJ DZ EG IQ IR JO …"/> |
| … |
| <weekendStart day="sat" territories="001"/> |
| <weekendStart day="sun" territories="IN"/> |
| <weekendStart day="thu" territories="AF DZ IR OM SA YE"/> |
| <weekendStart day="fri" territories="AE BH EG IL IQ JO KW …"/> |
| … |
| <weekOfPreference ordering="weekOfYear" locales="und"/> |
| <weekOfPreference ordering="weekOfYear weekOfMonth" locales="am az bs cs cy da el et hi ky lt mk sk ta th"/> |
| <weekOfPreference ordering="weekOfYear weekOfMonth weekOfInterval" locales="is mn no sv vi"/> |
| <weekOfPreference ordering="weekOfYear weekOfDate weekOfMonth" locales="fi zh-TW"/> |
| … |
| </pre> |
| <p>In order for a week to count as the first week of a new year |
| for week-of-year calculations, it must include at least the |
| number of days in the new year specified by the minDays value; |
| otherwise the week will count as the last week of the previous |
| year (and for week-of-month calculations, minDays also |
| specifies the minimum number of days in the new month for a |
| week to count as part of that month).</p> |
| <p>The day indicated by firstDay is the one that should be |
| shown as the first day of the week in a calendar view. This is |
| not necessarily the same as the first day after the weekend (or |
| the first work day of the week), which should be determined |
| from the weekend information. Currently, day-of-week numbering |
| is based on firstDay (that is, day 1 is the day specified by |
| firstDay), but in the future we may add a way to specify this |
| separately.</p> |
| <p>What is meant by the weekend varies from country to country. |
| It is typically when most non-retail businesses are closed. The |
| time should not be specified unless it is a well-recognized |
| part of the day. The weekendStart day defaults to "sat", and |
| weekendEnd day defaults to "sun". For more information, see |
| <i><a href="tr35.html#Date_Ranges">Dates and Date |
| Ranges</a></i>.</p> |
| <p>Each weekOfPreference element provides, for its specified |
| locales, an ordered list of the preferred types of week |
| designations for that set of locales. There are four types of |
| week designations, each of which makes use of date patterns |
| available in the locale, as follows:</p> |
| <table cellspacing="0" cellpadding="4" border="1"> |
| <caption> |
| <a name="Week_Designation_Types" href= |
| "#Week_Designation_Types" id="Week_Designation_Types">Week |
| Designation Types</a> |
| </caption> |
| <tr> |
| <th width="10%">Type</th> |
| <th width="20%">Examples</th> |
| <th width="30%">Date Pattern</th> |
| <th width="40%">Comments</th> |
| </tr> |
| <tr> |
| <td width="10">weekOfYear</td> |
| <td width="20%">week 15 of 2016</td> |
| <td width="30%"><dateFormatItem id='yw' |
| count='one'>'week' w 'of' <span style= |
| "text-align: center">Y<…</span></td> |
| <td width="40%" rowspan="2">The <em>week of</em> |
| construction takes a <strong>count</strong> attribute, just |
| in case the pattern changes depending on the numeric value. |
| (In the future, we're likely to add an ordinal value, for |
| constructions like “3rd week of March”.)<br> |
| In languages where the month name needs grammatical changes |
| (aside from just the simple addition of a prefix or |
| suffix), localizers will typically use a work-around |
| construction.</td> |
| </tr> |
| <tr> |
| <td width="10%">weekOfMonth</td> |
| <td width="20%">week 2 of April<br> |
| 2nd week of April</td> |
| <td width="30%"><dateFormatItem id='MMMMW'' |
| count='one'>'week' W 'of' MMM<…</td> |
| </tr> |
| <tr> |
| <td width="10%">weekOfDate</td> |
| <td width="20%">the week of April 11, 2016</td> |
| <td width="30%" rowspan="2"><field |
| type="week"><relativePeriod>the week of |
| {0}<…</td> |
| <td width="40%" rowspan="2">The date pattern that replaces |
| {0} is determined separately and may use the first day or |
| workday of the week, the range of the full week or work |
| week, etc.</td> |
| </tr> |
| <tr> |
| <td width="10%">weekOfInterval</td> |
| <td width="20%">the week of April 11–15</td> |
| </tr> |
| </table> |
| <h3>4.4 <a name="Time_Data" href="#Time_Data" id= |
| "Time_Data">Time Data</a></h3> |
| <p class="dtd"><!ELEMENT timeData ( hours* ) ><br> |
| <!ELEMENT hours EMPTY ><br> |
| <!ATTLIST hours preferred NMTOKEN #REQUIRED ><br> |
| <!ATTLIST hours allowed NMTOKENS #REQUIRED ><br> |
| <!ATTLIST hours regions NMTOKENS #REQUIRED ></p> |
| <p>This element is for data that indicates, for various |
| regions, the preferred time cycle in the region, as well as all |
| time cycles that are considered acceptable in the region. The |
| defaults are those specified for region 001.</p> |
| <p>There is a single <code>preferred</code> value, and multiple |
| <code>allowed</code> values. The meanings of the values H, h, |
| K, k, b and B are defined in <a href= |
| "#Date_Field_Symbol_Table">Date Field Symbol Table</a>. The |
| <code>allowed</code> values are in preference order, and are |
| used with the 'C' hour skeleton pattern symbol.</p> |
| <p>For example, in the following, RU (Russia) is marked as |
| using only 24 hour time, and in particular the 24 hour time |
| that goes from 0..23 (H), rather than from 1..24 (k).</p> |
| <pre><timeData> |
| <hours preferred="H" allowed="H h" regions="001 …"/> |
| <hours preferred="H" allowed="H K h" regions="JP"/> |
| <hours preferred="H" allowed="H" regions="IL RU"/> |
| <hours preferred="h" allowed="H h" regions="AE AG AL … US … ZW"/> |
| …</pre> |
| <p>The B and b date symbols provide for formats like “3:00 at |
| night”. When the ‘C’ option is used, the values in |
| <code>allowed</code> are traversed from first to last, picking |
| the first available format. For example, in the following a |
| system that supports hB should choose that as the most |
| preferred format for the C (not the <code>preferred</code> |
| value H).</p> |
| <pre><hours preferred="H" allowed="hB H" regions="CD"/> |
| <hours preferred="H" allowed="hB hb h H" regions="KE MM TZ UG"/> |
| </pre>Some systems may not want to use B and b, even if preferred |
| for the locale, so for compatibility the <code>preferred</code> |
| value is limited to {H, h, K, k}, and is the option selected by the |
| ‘j’ date symbol. Thus the <code>preferred</code> value may not be |
| the same as the first <code>allowed</code> value. |
| <h3>4.5 <a name="Day_Period_Rule_Sets" href= |
| "#Day_Period_Rule_Sets" id="Day_Period_Rule_Sets">Day Period |
| Rule Sets</a></h3> |
| <p class="dtd"><!ELEMENT dayPeriodRuleSet ( dayPeriodRules* |
| ) ><br> |
| <!ATTLIST dayPeriodRuleSet type NMTOKEN #IMPLIED ></p> |
| <p class="dtd"><!ELEMENT dayPeriodRules (dayPeriodRule*) |
| ><br> |
| <!ATTLIST dayPeriodRules locales NMTOKENS #REQUIRED ></p> |
| <p class="dtd"><!ELEMENT dayPeriodRule EMPTY ><br> |
| <!ATTLIST dayPeriodRule type NMTOKEN #REQUIRED ><br> |
| <!ATTLIST dayPeriodRule at NMTOKEN #IMPLIED ><br> |
| <!ATTLIST dayPeriodRule from NMTOKEN #IMPLIED ><br> |
| <!ATTLIST dayPeriodRule before NMTOKEN #IMPLIED ><br></p> |
| <p>Each locale can have a set of day period rules, which |
| determine the periods during a day for use in time formats like |
| "10:00 at night", or to select statements like "Your email |
| arrived last night." If locales do not have dayPeriodRules, the |
| computation of dayPeriods falls back to AM/PM.</p> |
| <p>There are two kinds of dayPeriodRuleSets, based on the |
| type:</p> |
| <p>The <strong><em>format</em></strong> type is used in |
| conjunction with times, such as to express "3:00 in the |
| afternoon", or "12:00 noon". Many languages do not normally use |
| terms that match AM/PM for such times, instead breaking up the |
| day into more periods.</p> |
| <p>The <strong>stand-alone</strong> type is used for selecting |
| a period of the day for a general time associated with an |
| event. For example, it can be used to select a message |
| like:</p> |
| <p class='xmlExample'><msg ... ><br> |
| {day_period, select,<br> |
| MORNING1 {Your email arrived yesterday morning.}<br> |
| AFTERNOON1 {Your email arrived yesterday afternoon.}<br> |
| EVENING1 {Your email arrived yesterday evening.}<br> |
| NIGHT1 {Your email arrived last night.}<br> |
| other {Your email arrived yesterday.}<br> |
| ...<br> |
| }<br> |
| </msg></p> |
| <p>The translated values for the selection |
| (<strong>stand-alone</strong>) day periods are intended for use |
| in designating a time of day, without an hour value.</p> |
| <p>These are relative times within a single day. If the event |
| can occur on multiple days, then that needs to be handled at a |
| higher level.</p> |
| <p>As with plurals, the exact set of periods used for any |
| language may be different. It is the responsibility of any |
| translation software to pick the relevant day periods for the |
| locale for display to the translator (and end user).</p> |
| <h4>4.5.1 <a name="Day_Period_Rules" href="#Day_Period_Rules" |
| id="Day_Period_Rules">Day Period Rules</a></h4> |
| <p>Here are the requirements for a rule set.</p> |
| <h5><a name="Fixed_periods" href="#Fixed_periods" id= |
| "Fixed_periods">4.5.1.1 Fixed periods</a></h5>There are 4 |
| dayPeriods that are fixed; am/pm are always defined, and always |
| have the same meaning and definition for every locale. Midnight |
| and noon are optional, however if they are defined, they have |
| the same meaning and definition as in all other locales where |
| they are defined. |
| <pre><dayPeriodRule type="midnight" at="00:00"/> |
| <dayPeriodRule type="am" from="00:00" before="12:00" /> |
| <dayPeriodRule type="noon" at="12:00"/> |
| <dayPeriodRule type="pm" from="12:00" before="24:00" /> |
| </pre> |
| <p>Note that midnight and am can overlap, as can noon and |
| pm.<br></p> |
| <p>All locales must support am/pm, but not all support |
| <strong>noon</strong> or <strong>midnight</strong>; they are |
| only supported if they meet the above definitions. For example, |
| German has no unique term that means exactly 12:00 noon; the |
| closest is Mittag, but that can extend before or after 12 |
| noon.</p> |
| <p><strong>Midnight</strong> is also special, since it can |
| refer to either 00:00 or 24:00 — either at the start or end of |
| the day. That means that Tuesday 24:00 = Wednesday 00:00. |
| “Midnight Tuesday" is thus ambiguous: it means 24:00 in “the |
| party is Tuesday from 10pm to 12 midnight”, while it means |
| 00:00 in “I was awake from 12 midnight to 3 in the |
| morning”.</p> |
| <p>It is strongly recommended that implementations provide for |
| the ability to specify whether <strong>midnight</strong> is |
| supported or not (and for either 00:00 or 24:00 or both), since |
| only the caller knows enough of the context to determine what |
| to use. In the absence of such information, 24:00 may be the |
| best choice.<br></p> |
| <h5><a name="Variable_periods" href="#Variable_periods" id= |
| "Variable_periods">4.5.1.2 Variable periods</a></h5> |
| <ol> |
| <li>If a locale has a set of dayPeriodRules for variable |
| periods, it needs to completely cover the 24 hours in a day |
| (from 0:00 before 24:00), with |
| <strong>no</strong> overlaps between |
| any dayPeriodRules. They may overlap with the |
| <strong>Fixed Periods</strong>.<br> |
| If it does not have a rule set for variable periods, behavior |
| should fall back to using the fixed periods (am, pm).</li> |
| <li>"from" is a closed interval (inclusive). <em>(as is the |
| deprecated "to")</em></li> |
| <li>"before" is an open interval (exclusive). <em>(as is the |
| deprecated "after")</em></li> |
| <li>"at" means starting time and end time are the same. |
| <em>("at" is deprecated except when used for the fixed |
| periods)</em></li> |
| <li>There must be exactly one of {at, from, after} and |
| exactly one of {at, to, before} for |
| each dayPeriodRule.</li> |
| <li>Use of non-zero minutes or seconds is deprecated.</li> |
| <li>The dayPeriodRules for format must allow that hh:mm |
| [period name] and hh [period name] can be parsed uniquely to |
| HH:mm [period name]. |
| <ul> |
| <li>For example, you can't have <dayPeriod type = |
| "morning1" from="00:00" to="13:00"/> because "12:30 |
| {morning}" would be ambiguous.</li> |
| </ul> |
| </li> |
| <li>There must not be two rules with the same type. A day |
| period rule may, however, span 24:00 / 00:00. Example: |
| <ul> |
| <li> |
| <em>Valid:</em> |
| <ul> |
| <li><dayPeriod type = "night1" from="21:00" |
| to="05:00"/></li> |
| </ul> |
| </li> |
| <li> |
| <em>Invalid:</em> |
| <ul> |
| <li><dayPeriod type = "night1" from="00:00" |
| to="05:00"/></li> |
| <li><dayPeriod type = "night1" from="21:00" |
| to="24:00"/></li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| <li>24:00 is <em>only</em> allowed |
| in <em>before</em>="24:00".</li> |
| </ol> |
| <h5><a name="Parsing_Day_Periods" href="#Parsing_Day_Periods" |
| id="Parsing_Day_Periods">4.5.1.3 Parsing Day Periods</a></h5> |
| <p>When parsing, if the hour is present with a strict parse the |
| dayperiod is checked for consistency with the hour. If there is |
| no hour, the center of the first |
| matching dayPeriodRule can be chosen (starting |
| from 0:00). However, if there is other information available |
| when parsing, a different point within the interval may be |
| chosen.</p> |
| <p>The dayPeriodRule may span two days, such as where |
| <strong>night1</strong> is [21:00, 06:00). In that case, the |
| midpoint is 01:30, so when parsing “Nov 12, at night”, the |
| midpoint result would be Nov 12, 01:30. “Nov 12, am”, “Nov 12, |
| pm”, “Nov 12, noon” can be parsed similarly, resulting in Nov |
| 12, 06:00; Nov 12, 18:00; and Nov 12, 12:00; respectively.</p> |
| <p>“Nov 12, midnight” is special, because midnight may mean |
| either 00:00 or 24:00. Extra information may be needed to |
| disambiguate which is meant, such as whether the time is at the |
| start or end of an interval. In the absence of such |
| information, 24:00 may be the best choice. See the discussion |
| of <strong>midnight</strong> above.</p> |
| <p>If rounding is done—including the rounding done by the time |
| format—then it needs to be done before the dayperiod is |
| computed, so that the correct format is shown.</p> |
| <p>For examples, see <a href= |
| "http://www.unicode.org/cldr/charts/latest/supplemental/day_periods.html"> |
| Day Periods Chart</a>.</p> |
| <h2>5 <a name="Time_Zone_Names" href="#Time_Zone_Names" id= |
| "Time_Zone_Names">Time Zone Names</a></h2> |
| <p class="dtd"><!ELEMENT timeZoneNames (alias | |
| (hourFormat*, gmtFormat*, gmtZeroFormat*, regionFormat*, |
| fallbackFormat*, zone*, metazone*, special*)) ></p> |
| <p class="dtd"><!ELEMENT hourFormat ( #PCDATA ) ><br> |
| <!ELEMENT gmtFormat ( #PCDATA ) ><br> |
| <!ELEMENT gmtZeroFormat ( #PCDATA ) ></p> |
| <p class="dtd"><!ELEMENT regionFormat ( #PCDATA ) ><br> |
| <!ATTLIST regionFormat type ( standard | daylight ) #IMPLIED |
| ></p> |
| <p class="dtd"><!ELEMENT fallbackFormat ( #PCDATA ) ></p> |
| <p class="dtd"><!ELEMENT zone (alias | ( long*, short*, |
| exemplarCity*, special*)) ><br> |
| <!ATTLIST zone type CDATA #REQUIRED ></p> |
| <p class="dtd"><!ELEMENT metazone (alias | ( long*, short*, |
| special*)) ><br> |
| <!ATTLIST metazone type CDATA #REQUIRED ></p> |
| <p class="dtd"><!ELEMENT long (alias | (generic*, standard*, |
| daylight*, special*)) ><br> |
| <!ELEMENT short (alias | (generic*, standard*, daylight*, |
| special*)) ></p> |
| <p class="dtd"><!ELEMENT generic ( #PCDATA ) ><br> |
| <!ELEMENT standard ( #PCDATA ) ><br> |
| <!ELEMENT daylight ( #PCDATA ) ></p> |
| <p class="dtd"><!ELEMENT exemplarCity ( #PCDATA ) ></p> |
| <p>The time zone IDs (tzid) are language-independent, and |
| follow the <i>TZ time zone database</i> [<a href= |
| "tr35.html#Olson">Olson</a>] and naming conventions. However, |
| the display names for those IDs can vary by locale. The generic |
| time is so-called <i>wall-time</i>; what clocks use when they |
| are correctly switched from standard to daylight time at the |
| mandated time of the year.</p> |
| <p>Unfortunately, the canonical tzid's (those in zone.tab) are |
| not stable: may change in each release of the <i>TZ</i> Time |
| Zone database. In CLDR, however, stability of identifiers is |
| very important. So the canonical IDs in CLDR are kept stable as |
| described in <a href="tr35.html#Canonical_Form">Canonical |
| Form</a>.</p> |
| <p>The <i>TZ time zone database</i> can have multiple IDs that |
| refer to the same entity. It does contain information on |
| equivalence relationships between these IDs, such as |
| "Asia/Calcutta" and "Asia/Kolkata". It does not remove IDs |
| (with a few known exceptions), but it may change the |
| "canonical" ID which is in the file zone.tab.</p> |
| <p>For lookup purposes specifications such as CLDR need a |
| stable canonical ID, one that does not change from release to |
| release. The stable ID is maintained as the first alias item |
| <i>type</i> element in the file bcp47/timezone.xml, such |
| as:</p> |
| <pre> |
| <type name="inccu" alias="Asia/Calcutta Asia/Kolkata"/></pre> |
| <p>That file also contains the short ID used in keywords. In |
| versions of CLDR previous to 1.8, the alias information (but |
| not the short ID) was in Supplemental Data under the zoneItem, |
| such as:</p> |
| <pre> |
| <zoneItem type="Asia/Calcutta" territory="IN" aliases="Asia/Kolkata"/></pre> |
| <p>This element was deprecated after the introduction of |
| bcp47/timezone.xml, because the information became redundant |
| (or was contained in the <i>TZ time zone database</i>).</p> |
| <p>The following is an example of time zone data. Although this |
| is an example of possible data, in most cases only the |
| exemplarCity needs translation. And that does not even need to |
| be present, if a country only has a single time one. As always, |
| the <i>type</i> field for each zone is the identification of |
| that zone. It is not to be translated.</p> |
| <pre><zone type="<span style= |
| "color: blue">America/Los_Angeles</span>"> |
| <long> |
| <generic><span style= |
| "color: blue">Pacific Time</span></generic> |
| <standard><span style= |
| "color: blue">Pacific Standard Time</span></standard> |
| <daylight><span style= |
| "color: blue">Pacific Daylight Time</span></daylight> |
| </long> |
| <short> |
| <generic><span style= |
| "color: blue">PT</span></generic> |
| <standard><span style= |
| "color: blue">PST</span></standard> |
| <daylight><span style= |
| "color: blue">PDT</span></daylight> |
| </short> |
| <exemplarCity><span style= |
| "color: blue">San Francisco</span></exemplarCity> |
| </zone> |
| |
| <zone type="<span style="color: blue">Europe/London</span>"> |
| <long> |
| <generic><span style= |
| "color: blue">British Time</span></generic> |
| <standard><span style= |
| "color: blue">British Standard Time</span></standard> |
| <daylight><span style= |
| "color: blue">British Daylight Time</span></daylight> |
| </long> |
| <exemplarCity><span style= |
| "color: blue">York</span></exemplarCity> |
| </zone>\ |
| </pre> |
| <p>In a few cases, some time zone IDs do not designate a city, |
| as in:</p> |
| <pre><zone type="<span style= |
| "color: blue">America/Puerto_Rico</span>"> |
| ... |
| </zone> |
| |
| <zone type="<span style="color: blue">America/Guyana</span>"> |
| ... |
| </zone> |
| |
| <zone type="<span style="color: blue">America/Cayman</span>"> |
| ... |
| </zone> |
| |
| <zone type="<span style= |
| "color: blue">America/St_Vincent</span>"> |
| ... |
| </zone> |
| </pre> |
| <p>They may designate countries or territories; their actual |
| capital city may be a name that is too common, or, too |
| uncommon. CLDR time zone IDs follow the <a href= |
| "tr35.html#Olson">Olson</a> naming conventions.</p> |
| <blockquote> |
| <p class="note"><b>Note:</b> CLDR does not allow "GMT", "UT", |
| or "UTC" as translations (short or long) of time zones other |
| than GMT itself.</p> |
| </blockquote> |
| <blockquote> |
| <p class="note"><b>Note:</b> Transmitting "14:30" with no |
| other context is incomplete unless it contains information |
| about the time zone. Ideally one would transmit |
| neutral-format date/time information, commonly in UTC (GMT), |
| and localize as close to the user as possible. (For more |
| about UTC, see [<a href= |
| "tr35.html#UTCInfo">UTCInfo</a>].)</p> |
| </blockquote> |
| <p class="note">The conversion from local time into UTC depends |
| on the particular time zone rules, which will vary by location. |
| The standard data used for converting local time (sometimes |
| called <i>wall time</i>) to UTC and back is the <i>TZ Data</i> |
| [<a href="tr35.html#Olson">Olson</a>], used by Linux, UNIX, |
| Java, ICU, and others. The data includes rules for matching the |
| laws for time changes in different countries. For example, for |
| the US it is:</p> |
| <blockquote> |
| <p>"During the period commencing at 2 o'clock antemeridian on |
| the second Sunday of March of each year and ending at 2 |
| o'clock antemeridian on the first Sunday of November of each |
| year, the standard time of each zone established by sections |
| 261 to 264 of this title, as modified by section 265 of this |
| title, shall be advanced one hour..." (United States Law - 15 |
| U.S.C. §6(IX)(260-7), as amended by Energy Policy Act of |
| 2005).</p> |
| </blockquote> |
| <p class="note">Each region that has a different time zone or |
| daylight savings time rules, either now or at any time back to |
| 1970, is given a unique internal ID, such as |
| <code>Europe/Paris</code> . (Some IDs are also distinguished on |
| the basis of differences before 1970.) As with currency codes, |
| these are internal codes. A localized string associated with |
| these is provided for users (such as in the Windows <i>Control |
| Panels>Date/Time>Time Zone</i>).</p> |
| <p class="note">Unfortunately, laws change over time, and will |
| continue to change in the future, both for the boundaries of |
| time zone regions and the rules for daylight savings. Thus the |
| <i>TZ</i> data is continually being augmented. Any two |
| implementations using the same version of the <i>TZ</i> data |
| will get the same results for the same IDs (assuming a correct |
| implementation). However, if implementations use different |
| versions of the data they may get different results. So if |
| precise results are required then both the <i>TZ</i> ID and the |
| <i>TZ</i> data version must be transmitted between the |
| different implementations.</p> |
| <p class="note">For more information, see [<a href= |
| "tr35.html#DataFormats">Data Formats</a>].</p> |
| <p>The following subelements of <timeZoneNames> are used |
| to control the fallback process described in <a href= |
| "#Using_Time_Zone_Names">Using Time Zone Names</a>.</p> |
| <table cellspacing="0" cellpadding="4" border="1"> |
| <caption> |
| <a name="timeZoneNames_Elements_Used_for_Fallback" href= |
| "#timeZoneNames_Elements_Used_for_Fallback" id= |
| "timeZoneNames_Elements_Used_for_Fallback"><timeZoneNames> |
| Elements Used for Fallback</a> |
| </caption> |
| <tr> |
| <th>Element Name</th> |
| <th>Data Examples</th> |
| <th>Results/Comment</th> |
| </tr> |
| <tr> |
| <td rowspan="2">hourFormat</td> |
| <td rowspan="2">"+HHmm;-HHmm"</td> |
| <td>"+1200"</td> |
| </tr> |
| <tr> |
| <td>"-1200"</td> |
| </tr> |
| <tr> |
| <td rowspan="2">gmtFormat</td> |
| <td>"GMT{0}"</td> |
| <td>"GMT-0800"</td> |
| </tr> |
| <tr> |
| <td>"{0}ВпГ"</td> |
| <td>"-0800ВпГ"</td> |
| </tr> |
| <tr> |
| <td>gmtZeroFormat</td> |
| <td>"GMT"</td> |
| <td>Specifies how GMT/UTC with no explicit offset (implied |
| 0 offset) should be represented.</td> |
| </tr> |
| <tr> |
| <td rowspan="2">regionFormat</td> |
| <td>"{0} Time"</td> |
| <td>"Japan Time"</td> |
| </tr> |
| <tr> |
| <td>"Hora de {0}"</td> |
| <td>"Hora de Japón"</td> |
| </tr> |
| <tr> |
| <td rowspan="2">regionFormat type="daylight"<br> |
| (or "standard")</td> |
| <td>"{0} Daylight Time"</td> |
| <td>"France Daylight Time"</td> |
| </tr> |
| <tr> |
| <td>"horario de verano de {0}"</td> |
| <td>"horario de verano de Francia"</td> |
| </tr> |
| <tr> |
| <td>fallbackFormat</td> |
| <td>"{1} ({0})"</td> |
| <td>"Pacific Time (Canada)"</td> |
| </tr> |
| </table> |
| <p>When referring to the abbreviated (short) form of the time |
| zone name, there are often situations where the location-based |
| (city or country) time zone designation for a particular |
| language may not be in common usage in a particular |
| territory.</p> |
| <blockquote> |
| <p class="note"><b>Note:</b> User interfaces for time zone |
| selection can use the "generic location format" for time zone |
| names to obtain the most useful ordering of names in a menu |
| or list; see <i><a href="#Using_Time_Zone_Names">Using Time |
| Zone Names</a></i> and the zone section of the <i><a href= |
| "#Date_Field_Symbol_Table">Date Field Symbol |
| Table</a>.</i></p> |
| </blockquote> |
| <h3>5.1 <a name="Metazone_Names" href="#Metazone_Names" id= |
| "Metazone_Names">Metazone Names</a></h3> |
| <p>A metazone is an grouping of one or more internal TZIDs that |
| share a common display name in current customary usage, or that |
| have shared a common display name during some particular time |
| period. For example, the zones <i>Europe/Paris, Europe/Andorra, |
| Europe/Tirane, Europe/Vienna, Europe/Sarajevo, Europe/Brussels, |
| Europe/Zurich, Europe/Prague, Europe/Berlin</i>, and so on are |
| often simply designated <i>Central European Time</i> (or |
| translated equivalent).</p> |
| <p>A metazone's display fields become a secondary fallback if |
| an appropriate data field cannot be found in the explicit time |
| zone data. The <i>usesMetazone</i> field indicates that the |
| target metazone is active for a particular time. This also |
| provides a mechanism to effectively deal with situations where |
| the time zone in use has changed for some reason. For example, |
| consider the TZID "America/Indiana/Knox", which observed |
| Central time (GMT-6:00) prior to October 27, 1991, and has |
| currently observed Central time since April 2, 2006, but has |
| observed Eastern time ( GMT-5:00 ) between these two dates. |
| This is denoted as follows</p> |
| <pre><timezone type="America/Indiana/Knox"> |
| <usesMetazone to="1991-10-27 07:00" mzone="America_Central"/> |
| <usesMetazone to="2006-04-02 07:00" from="1991-10-27 07:00" mzone="America_Eastern"/> |
| <usesMetazone from="2006-04-02 07:00" mzone="America_Central"/> |
| </timezone></pre> |
| <p>Note that the dates and times are specified in UTC, not |
| local time.</p> |
| <p>The metazones can then have translations in different locale |
| files, such as the following.</p> |
| <pre><metazone type="America_Central"> |
| <long> |
| <generic>Central Time</generic> |
| <standard>Central Standard Time</standard> |
| <daylight>Central Daylight Time</daylight> |
| </long> |
| <short> |
| <generic>CT</generic> |
| <standard>CST</standard> |
| <daylight>CDT</daylight> |
| </short> |
| </metazone> |
| <metazone type="America_Eastern"> |
| <long> |
| <generic>Eastern Time</generic> |
| <standard>Eastern Standard Time</standard> |
| <daylight>Eastern Daylight Time</daylight> |
| </long> |
| <short> |
| <generic>ET</generic> |
| <standard>EST</standard> |
| <daylight>EDT</daylight> |
| </short> |
| </metazone></pre> |
| <pre><metazone type="America_Eastern"> |
| <long> |
| <generic>Heure de l’Est</generic> |
| <standard>Heure normale de l’Est</standard> |
| <daylight>Heure avancée de l’Est</daylight> |
| </long> |
| <short> |
| <generic>HE</generic> |
| <standard>HNE</standard> |
| <daylight>HAE</daylight> |
| </short> |
| </metazone> |
| </pre> |
| <p>When formatting a date and time value using this data, an |
| application can properly be able to display "Eastern Time" for |
| dates between 1991-10-27 and 2006-04-02, but display "Central |
| Time" for current dates. (See also <i><a href= |
| "tr35.html#Date_Ranges">Dates and Date Ranges</a></i>).</p> |
| <p>Metazones are used with the 'z', 'zzzz', 'v', and 'vvvv date |
| time pattern characters, and not with the 'Z', 'ZZZZ', 'VVVV' |
| and other pattern characters for time zone formatting. For more |
| information, see <a href="#Date_Format_Patterns"><u>Date Format |
| Patterns</u></a> .</p> |
| <p>The commonlyUsed element is now deprecated. The CLDR |
| committee has found it nearly impossible to obtain accurate and |
| reliable data regarding which time zone abbreviations may be |
| understood in a given territory, and therefore has changed to a |
| simpler approach. Thus, if the short metazone form is available |
| in a given locale, it is to be used for formatting regardless |
| of the value of commonlyUsed. If a given short metazone form is |
| known NOT to be understood in a given locale and the parent |
| locale has this value such that it would normally be inherited, |
| the inheritance of this value can be explicitly disabled by use |
| of the 'no inheritance marker' as the value, which is 3 |
| simultaneous empty set characters ( U+2205 ).</p> |
| <h2>6 <a name="Supplemental_Time_Zone_Data" href= |
| "#Supplemental_Time_Zone_Data" id= |
| "Supplemental_Time_Zone_Data">Supplemental Time Zone |
| Data</a></h2> |
| <h3>6.1 <a name="Metazones" href="#Metazones" id= |
| "Metazones">Metazones</a></h3> |
| <p class="dtd"><!ELEMENT metaZones (metazoneInfo?, |
| mapTimezones?) ><br></p> |
| <p class="dtd"><!ELEMENT metazoneInfo (timezone*) ></p> |
| <p class="dtd"><!ELEMENT timezone (usesMetazone*) ><br> |
| <!ATTLIST timezone type CDATA #REQUIRED ></p> |
| <p class="dtd"><!ELEMENT usesMetazone EMPTY ><br> |
| <!ATTLIST usesMetazone mzone NMTOKEN #REQUIRED ><br> |
| <!ATTLIST usesMetazone from CDATA #IMPLIED ><br> |
| <!ATTLIST usesMetazone to CDATA #IMPLIED ></p> |
| <p class="dtd"><!ELEMENT mapTimezones ( mapZone* ) ><br> |
| <!ATTLIST mapTimezones type NMTOKEN #IMPLIED ><br> |
| <!ATTLIST mapTimezones typeVersion CDATA #IMPLIED ><br> |
| <!ATTLIST mapTimezones otherVersion CDATA #IMPLIED ><br> |
| <!ATTLIST mapTimezones references CDATA #IMPLIED ></p> |
| <p class="dtd"><!ELEMENT mapZone EMPTY ><br> |
| <!ATTLIST mapZone type CDATA #REQUIRED ><br> |
| <!ATTLIST mapZone other CDATA #REQUIRED ><br> |
| <!ATTLIST mapZone territory CDATA #IMPLIED ><br> |
| <!ATTLIST mapZone references CDATA #IMPLIED ></p> |
| <p>The following subelement of <metaZones> provides a |
| mapping from a single Unicode time zone id to metazones. For |
| more information about metazones, See <i><a href= |
| "tr35-dates.html#Time_Zone_Names">Time Zone Names</a></i>.</p> |
| <pre><metazoneInfo> |
| <timezone type="Europe/Andorra"> |
| <usesMetazone mzone="Europe_Central"/> |
| </timezone> |
| .... |
| <timezone type="Asia/Yerevan"> |
| <usesMetazone to="1991-09-22 20:00" mzone="Yerevan"/> |
| <usesMetazone from="1991-09-22 20:00" mzone="Armenia"/> |
| </timezone> |
| .... |
| </pre> |
| <p>The following subelement of <metaZones> specifies a |
| mapping from a metazone to golden zones for each territory. For |
| more information about golden zones, see <i><a href= |
| "tr35-dates.html#Using_Time_Zone_Names">Using Time Zone |
| Names</a></i>.</p> |
| <pre><mapTimezones type="metazones"> |
| <mapZone other="Acre" territory="001" type="America/Rio_Branco"/> |
| <mapZone other="Afghanistan" territory="001" type="Asia/Kabul"/> |
| <mapZone other="Africa_Central" territory="001" type="Africa/Maputo"/> |
| <mapZone other="Africa_Central" territory="BI" type="Africa/Bujumbura"/> |
| <mapZone other="Africa_Central" territory="BW" type="Africa/Gaborone"/> |
| .... |
| </pre> |
| <h3>6.2 <a name="Windows_Zones" href="#Windows_Zones" id= |
| "Windows_Zones">Windows Zones</a></h3> |
| <p class="dtd"><!ELEMENT windowsZones (mapTimezones?) |
| ></p> |
| <p>The <mapTimezones> element can be also used to provide |
| mappings between Unicode time zone IDs and other time zone IDs. |
| This example specifies a mapping from Windows TZIDs to Unicode |
| time zone IDs .</p> |
| <pre> |
| <mapTimezones otherVersion="07dc0000" typeVersion="2011n"> |
| .... |
| <!-- (UTC-08:00) Baja California --> |
| <mapZone other="Pacific Standard Time (Mexico)" territory="001" type="America/Santa_Isabel"/> |
| <mapZone other="Pacific Standard Time (Mexico)" territory="MX" type="America/Santa_Isabel"/> |
| |
| <!-- (UTC-08:00) Pacific Time (US & Canada) --> |
| <mapZone other="Pacific Standard Time" territory="001" type="America/Los_Angeles"/> |
| <mapZone other="Pacific Standard Time" territory="CA" type="America/Vancouver America/Dawson America/Whitehorse"/> |
| <mapZone other="Pacific Standard Time" territory="MX" type="America/Tijuana"/> |
| <mapZone other="Pacific Standard Time" territory="US" type="America/Los_Angeles"/> |
| <mapZone other="Pacific Standard Time" territory="ZZ" type="PST8PDT"/> |
| .... |
| </pre> |
| <p>The attributes otherVersion and typeVersion in |
| <mapTimezones> specify the versions of two systems. In |
| the example above, otherVersion="07dc0000" specifies the |
| version of Windows time zone and typeVersion="2011n" specifies |
| the version of Unicode time zone IDs. The attribute |
| territory="001" in <mapZone> element indicates the long |
| canonical Unicode time zone ID specified by the type attribute |
| is used as the default mapping for the Windows TZID. For each |
| unique Windows TZID, there must be exactly one <mapZone> |
| element with territory="001". <mapZone> elements other |
| than territory="001" specify territory specific mappings. When |
| multiple Unicode time zone IDs are available for a single |
| territory, the value of the type attribute will be a list of |
| Unicode time zone IDs delimited by space. In this case, the |
| first entry represents the default mapping for the territory. |
| The territory "ZZ" is used when a Unicode time zone ID is not |
| associated with a specific territory.</p> |
| <p><b>Note:</b> The long canonical Unicode time zone ID might |
| be deprecated in the tz database[<a href= |
| "tr35.html#Olson">Olson</a>]. For example, CLDR uses |
| "Asia/Culcutta" as the long canonical time zone ID for Kolkata, |
| India. The same ID was moved to 'backward' file and replaced |
| with a new ID "Asia/Kolkata" in the tz database. Therefore, if |
| you want to get an equivalent Windows TZID for a zone ID in the |
| tz dadtabase, you have to resolve the long canonical Unicode |
| time zone ID (e.g. "Asia/Culcutta") for the zone ID (e.g. |
| "Asia/Kolkata"). For more details, see <a href= |
| "tr35.html#Time_Zone_Identifiers">Section 3.7.1.2 Time Zone |
| Identifiers</a>.</p> |
| <p><b>Note:</b> Not all Unicode time zones have equivalent |
| Windows TZID mappings. Also, not all Windows TZIDs have |
| equivalent Unicode time zones. For example, there is no |
| equivalent Windows zone for Unicode time zone |
| "Australia/Lord_Howe", and there is no equivalent Unicode time |
| zone for Windows zone "E. Europe Standard Time" (as of CLDR 25 |
| release).</p> |
| <h3>6.3 <a name="Primary_Zones" href="#Primary_Zones" id= |
| "Primary_Zones">Primary Zones</a></h3> |
| <p class="dtd"><!ELEMENT primaryZones ( primaryZone* ) |
| ><br> |
| <!ELEMENT primaryZone ( #PCDATA ) ><br> |
| <!ATTLIST primaryZone iso3166 NMTOKEN #REQUIRED ></p> |
| <p>This element is for data that is used to format a time |
| zone’s generic location name. Each <primaryZone> element |
| specifies the dominant zone for a region; this zone should use |
| the region name for its generic location name even though there |
| are other canonical zones available in the same region. For |
| example, Asia/Shanghai is displayed as "China Time", instead of |
| "Shanghai Time". Sample data:</p> |
| <pre><primaryZones> |
| <primaryZone iso3166="CL">America/Santiago</primaryZone> |
| <primaryZone iso3166="CN">Asia/Shanghai</primaryZone> |
| <primaryZone iso3166="DE">Europe/Berlin</primaryZone> |
| … |
| </pre> |
| <p>This information was previously specified by the LDML |
| <singleCountries> element under each locale’s |
| <timeZoneNames> element. However, that approach had |
| inheritance issues, and the data is not really locale-specific |
| anyway.</p> |
| <h2>7 <a name="Using_Time_Zone_Names" href= |
| "#Using_Time_Zone_Names" id="Using_Time_Zone_Names">Using Time |
| Zone Names</a></h2> |
| <p>There are three main types of formats for zone identifiers: |
| GMT, generic (wall time), and standard/daylight. Standard and |
| daylight are equivalent to a particular offset from GMT, and |
| can be represented by a GMT offset as a fallback. In general, |
| this is not true for the generic format, which is used for |
| picking timezones or for conveying a timezone for specifying a |
| recurring time (such as a meeting in a calendar). For either |
| purpose, a GMT offset would lose information.</p> |
| <h3>7.1 <a name="Time_Zone_Format_Terminology" href= |
| "#Time_Zone_Format_Terminology" id= |
| "Time_Zone_Format_Terminology">Time Zone Format |
| Terminology</a></h3> |
| <p>The following terminology defines more precisely the formats |
| that are used.</p> |
| <p><b>Generic non-location format:</b> Reflects "wall time" |
| (what is on a clock on the wall): used for recurring events, |
| meetings, or anywhere people do not want to be overly specific. |
| For example, "10 am Pacific Time" will be GMT-8 in the winter, |
| and GMT-7 in the summer.</p> |
| <ul> |
| <li>"Pacific Time" (long)</li> |
| <li>"PT" (short)</li> |
| </ul> |
| <p><b>Generic partial location format:</b> Reflects "wall |
| time": used as a fallback format when the generic non-location |
| format is not specific enough.</p> |
| <ul> |
| <li>"Pacific Time (Canada)" (long)</li> |
| <li>"PT (Whitehorse)" (short)</li> |
| </ul> |
| <p><b>Generic location format:</b> Reflects "wall time": a |
| primary function of this format type is to represent a time |
| zone in a list or menu for user selection of time zone. It is |
| also a fallback format when there is no translation for the |
| generic non-location format. Times can also be organized |
| hierarchically by country for easier lookup.</p> |
| <blockquote> |
| <p>France Time<br> |
| Italy Time<br> |
| Japan Time<br> |
| United States<br> |
| Chicago Time<br> |
| Denver Time<br> |
| Los Angeles Time<br> |
| New York Time<br> |
| United Kingdom Time</p> |
| </blockquote> |
| <p>Note: A generic location format is constructed by a part of |
| time zone ID representing an exemplar city name or its country |
| as the final fallback. However, there are Unicode time zones |
| which are not associated with any locations, such as |
| "Etc/GMT+5" and "PST8PDT". Although the date format pattern |
| "VVVV" specifies the generic location format, but it displays |
| localized GMT format for these. Some of these time zones |
| observe daylight saving time, so the result (localized GMT |
| format) may change depending on input date. For generating a |
| list for user selection of time zone with format "VVVV", these |
| non-location zones should be excluded.</p> |
| <p><b>Specific non-location format:</b> Reflects a specific |
| standard or daylight time, which may or may not be the wall |
| time. For example, "10 am Pacific Standard Time" will be GMT-8 |
| in the winter and in the summer.</p> |
| <ul> |
| <li>"Pacific Standard Time" (long)</li> |
| <li>"PST" (short)</li> |
| <li>"Pacific Daylight Time" (long)</li> |
| <li>"PDT" (short)</li> |
| </ul> |
| <p><b>Localized GMT format:</b> A constant, specific offset |
| from GMT (or UTC), which may be in a translated form. There are |
| two styles for this. The first is used when there is an |
| explicit non-zero offset from GMT; this style is specified by |
| the <gmtFormat> element and <hourFormat> element. |
| The long format always uses 2-digit hours field and minutes |
| field, with optional 2-digit seconds field. The short format is |
| intended for the shortest representation and uses hour fields |
| without leading zero, with optional 2-digit minutes and seconds |
| fields. The digits used for hours, minutes and seconds fields |
| in this format are the locale's default decimal digits:</p> |
| <ul> |
| <li>"GMT+03:30" (long)</li> |
| <li>"GMT+3:30" (short)</li> |
| <li>"UTC-03.00" (long)</li> |
| <li>"UTC-3" (short)</li> |
| <li>"Гриинуич+03:30" (long)</li> |
| </ul> |
| <p>Otherwise (when the offset from GMT is zero, referring to |
| GMT itself) the style specified by the <gmtZeroFormat> |
| element is used:</p> |
| <ul> |
| <li>"GMT"</li> |
| <li>"UTC"</li> |
| <li>"Гриинуич"</li> |
| </ul> |
| <p><b>ISO 8601 time zone formats:</b> The formats based on the |
| [<a href="tr35.html#ISO8601">ISO 8601</a>] local time |
| difference from UTC ("+" sign is used when local time offset is |
| 0), or the UTC indicator ("Z" - only when the local time offset |
| is 0 and the specifier X* is used). The ISO 8601 basic format |
| does not use a separator character between hours and minutes |
| field, while the extended format uses colon (':') as the |
| separator. The ISO 8601 basic format with hours and minutes |
| fields is equivalent to RFC 822 zone format.</p> |
| <ul> |
| <li>"-0800" (basic)</li> |
| <li>"-08" (basic - short)</li> |
| <li>"-08:00" (extended)</li> |
| <li>"Z" (UTC)</li> |
| </ul> |
| <blockquote> |
| <p class="note">Note: This specification extends the original |
| ISO 8601 formats and some format specifiers append seconds |
| field when necessary.</p> |
| </blockquote> |
| <p><b>Raw Offset</b> - an offset from GMT that does not include |
| any daylight savings behavior. For example, the raw offset for |
| Pacific Time is -8, even though the <i>observed offset</i> may |
| be -8 or -7.</p> |
| <p><b>Metazone</b> - a collection of time zones that share the |
| same behavior and same name during some period. They may differ |
| in daylight behavior (whether they have it and when).</p> |
| <p>For example, the TZID America/Cambridge_Bay is in the |
| following metazones during various periods:</p> |
| <blockquote> |
| <p><font size="2"><timezone |
| type="America/Cambridge_Bay"><br> |
| <usesMetazone to="1999-10-31 08:00" |
| mzone="America_Mountain"/><br> |
| <usesMetazone to="2000-10-29 07:00" from="1999-10-31 |
| 08:00" mzone="America_Central"/><br> |
| <usesMetazone to="2000-11-05 05:00" from="2000-10-29 |
| 07:00" mzone="America_Eastern"/><br> |
| <usesMetazone to="2001-04-01 09:00" from="2000-11-05 |
| 05:00" mzone="America_Central"/><br> |
| <usesMetazone from="2001-04-01 09:00" |
| mzone="America_Mountain"/><br> |
| </timezone></font></p> |
| </blockquote> |
| <p>Zones may join or leave a metazone over time. The data |
| relating between zones and metazones is in the supplemental |
| information; the locale data is restricted to translations of |
| metazones and zones.</p> |
| <blockquote> |
| <b>Invariants:</b> |
| <ul> |
| <li>At any given point in time, each zone belongs to no |
| more than one metazone.</li> |
| <li>At a given point in time, a zone may not belong to any |
| metazones.</li> |
| <li><i>Except for daylight savings</i>, at any given time, |
| all zones in a metazone have the same offset at that |
| time.</li> |
| </ul> |
| </blockquote> |
| <p><b>Golden Zone</b> - the TZDB zone that exemplifies a |
| metazone. For example, America/New_York is the golden zone for |
| the metazone America_Eastern:</p> |
| <blockquote> |
| <p><font size="2"><mapZone other="America_Eastern" |
| territory="001" type="America/New_York"/></font></p> |
| </blockquote> |
| <blockquote> |
| <b>Invariants:</b> |
| <ul> |
| <li style="margin-top: 0.5em; margin-bottom: 0.5em">The |
| golden zones are those in mapZone supplemental data under |
| the territory "001".</li> |
| <li style="margin-top: 0.5em; margin-bottom: 0.5em">Every |
| metazone has exactly one golden zone.</li> |
| <li style="margin-top: 0.5em; margin-bottom: 0.5em">Each |
| zone has at most one metazone for which it is golden.</li> |
| <li style="margin-top: 0.5em; margin-bottom: 0.5em">The |
| golden zone is in that metazone during the entire life of |
| the metazone. (The raw offset of the golden zone may change |
| over time.)</li> |
| <li>Each other zone must have the same raw offset as the |
| golden zone, for the entire period that it is in the |
| metazone. (It might not have the same offset when daylight |
| savings is in effect.)</li> |
| <li>A golden zone in mapTimezones must have reverse mapping |
| in metazoneInfo.</li> |
| <li>A single time zone can be a golden zone of multiple |
| different metazones if any two of them are never active at |
| a same time.</li> |
| </ul> |
| </blockquote> |
| <p><b>Preferred Zone</b> - for a given TZID, the "best" zone |
| out of a metazone for a given country or language.</p> |
| <blockquote> |
| <b>Invariants:</b> |
| <ul> |
| <li>The preferred zone for a given country XX are those in |
| mapZone supplemental data under the territory XX.</li> |
| <li style="margin-top: 0.5em; margin-bottom: 0.5em">Every |
| metazone has at most one preferred zone for a given |
| territory XX.</li> |
| <li style="margin-top: 0.5em; margin-bottom: 0.5em">Each |
| zone has at most one metazone for which it is preferred for |
| a territory XX.</li> |
| <li style="margin-top: 0.5em; margin-bottom: 0.5em">The |
| preferred zone for a given metazone and territory XX is in |
| a metazone M during any time when any other zone in XX is |
| also in M</li> |
| <li style="margin-top: 0.5em; margin-bottom: 0.5em">A |
| preferred zone in mapTimezones must have reverse mapping in |
| metazoneInfo</li> |
| </ul> |
| </blockquote> |
| <p>For example, for America_Pacific the preferred zone for |
| Canada is America/Vancouver, and the preferred zone for Mexico |
| is America/Tijuana. The golden zone is America/Los_Angeles, |
| which is also also the preferred zone for any other |
| country.</p> |
| <blockquote> |
| <p><font size="2"><mapZone other="America_Pacific" |
| territory="001" type="America/Los_Angeles"/><br> |
| <mapZone other="America_Pacific" territory="CA" |
| type="America/Vancouver"/><br> |
| <mapZone other="America_Pacific" territory="MX" |
| type="America/Tijuana"/></font></p> |
| </blockquote> |
| <p><a name="fallbackFormat" href="#fallbackFormat" id= |
| "fallbackFormat"><b>fallbackFormat</b>:</a> a formatting string |
| such as "{1} ({0})", where {1} is the metazone, and {0} is the |
| country or city.</p> |
| <p><b>regionFormat:</b> a formatting string such as "{0} Time", |
| where {0} is the country or city.</p> |
| <h3>7.2 <a name="Time_Zone_Goals" href="#Time_Zone_Goals" id= |
| "Time_Zone_Goals">Goals</a></h3> |
| <p>The timezones are designed so that:</p> |
| <blockquote> |
| <p>For any given locale, every <i>time</i> round trips with |
| all patterns (but not necessarily every timezone). That is, |
| given a time and a format pattern with a zone string, you can |
| format, then parse, and get back the same time.</p> |
| <p>Note that the round-tripping is not just important for |
| parsing; it provides for formatting dates and times in an |
| unambiguous way for users. It is also important for |
| testing.<br> |
| <br> |
| There are exceptions to the above for transition times.</p> |
| <ul> |
| <li>With generic format, time zone ID or exemplar city |
| name, during the transition when the local time maps to two |
| possible GMT times. |
| <ul> |
| <li>For example, Java works as follows, favoring |
| standard time:</li> |
| <li>Source: Sun Nov 04 01:30:00 PDT 2007</li> |
| <li>=> Formatted: "Sunday, November 4, 2007 1:30:00 |
| AM"</li> |
| <li>=> Parsed: Sun Nov 04 01:30:00 PST 2007</li> |
| </ul> |
| </li> |
| <li>When the timezone changes offset, say from GMT+4 to |
| GMT+5, there can also be a gap.</li> |
| </ul> |
| <p>The V/VV/VVV/VVVV format will roundtrip not only the time, |
| but the canonical timezone.</p> |
| </blockquote> |
| <p>When the data for a given format is not available, a |
| fallback format is used. The fallback order is given in the |
| following by a list.</p> |
| <ol> |
| <li> |
| <b>Specifics</b> |
| <ul> |
| <li>z - [short form] specific non-location |
| <ul> |
| <li>falling back to short localized GMT</li> |
| </ul> |
| </li> |
| <li>zzzz - [long form] specific non-location |
| <ul> |
| <li>falling back to long localized GMT</li> |
| </ul> |
| </li> |
| <li>Z/ZZZZZ/X+/x+ - ISO 8601 formats (no fallback |
| necessary)</li> |
| <li>ZZZZ/O+ - Localized GMT formats (no fallback |
| necessary)</li> |
| </ul> |
| </li> |
| <li> |
| <b>Generics</b> |
| <ul> |
| <li>v - [short form] generic non-location<br> |
| <i>(however, the rules are more complicated, see #5 |
| below)</i> |
| <ul> |
| <li>falling back to generic location</li> |
| <li>falling back to short localized GMT</li> |
| </ul> |
| </li> |
| <li>vvvv - [long form] generic non-location<br> |
| <i>(however, the rules are more complicated, see #5 |
| below)</i> |
| <ul> |
| <li>falling back to generic location</li> |
| <li>falling back to long localized GMT</li> |
| </ul> |
| </li> |
| <li>V - short time zone ID |
| <ul> |
| <li>falling back to the special ID "unk" |
| (Unknown)</li> |
| </ul> |
| </li> |
| <li>VV - long time zone ID (no fallback necessary, |
| because this is the input)</li> |
| <li>VVV - exemplar city |
| <ul> |
| <li>falling back to the localized exemplar city for |
| the unknown zone (Etc/Unknown), for example "Unknown |
| City" for English</li> |
| </ul> |
| </li> |
| <li>VVVV - generic location |
| <ul> |
| <li>falling back to long localized GMT</li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| </ol> |
| <p>The following process is used for the particular formats, |
| with the fallback rules as above.</p> |
| <p>Some of the examples are drawn from real data, while others |
| are for illustration. For illustration the region format is |
| "Hora de {0}". The fallback format in the examples is "{1} |
| ({0})", which is what is in root.</p> |
| <ol> |
| <li>In <b>all</b> cases, first canonicalize the <i>TZ</i> ID |
| according to the Unicode Locale Extension <i>type</i> mapping |
| data (See <a href="tr35.html#Time_Zone_Identifiers">Time Zone |
| Identifiers</a> for more details).. Use that canonical TZID |
| in each of the following steps. |
| <ul> |
| <li>America/Atka → America/Adak</li> |
| <li>Australia/ACT → Australia/Sydney</li> |
| </ul> |
| </li> |
| <li style="margin-top: 0.5em; margin-bottom: 0.5em">For the |
| localized GMT format, use the gmtFormat (such as "GMT{0}" or |
| "HMG{0}") with the hourFormat (such as "+HH:mm;-HH:mm" or |
| "+HH.mm;-HH.mm"). |
| <ul> |
| <li style="margin-top: 0.5em; margin-bottom: 0.5em"> |
| America/Los_Angeles → "GMT-08:00" // standard time</li> |
| <li style="margin-top: 0.5em; margin-bottom: 0.5em"> |
| America/Los_Angeles → "HMG-07:00" // daylight time</li> |
| <li style="margin-top: 0.5em; margin-bottom: 0.5em"> |
| Etc/GMT+3 → "GMT-03.00" // note that <i>TZ</i> tzids have |
| inverse polarity!</li> |
| </ul> |
| <p><b>Note:</b> The digits should be whatever are |
| appropriate for the locale used to format the time zone, |
| not necessarily from the western digits, 0..9. For example, |
| they might be from ०..९.</p> |
| </li> |
| <li>For ISO 8601 time zone format return the results |
| according to the ISO 8601 specification. |
| <ul> |
| <li>America/Los_Angeles → |
| <ul> |
| <li>"-08" ("X","x")</li> |
| <li>"-0800" ("Z","XX","XXXX","xx","xxxx")</li> |
| <li>"-08:00" |
| ("ZZZZZ","XXX","XXXXX","xxx","xxxxx")</li> |
| </ul> |
| </li> |
| <li>Etc/GMT → |
| <ul> |
| <li>"Z" ("ZZZZZ", "X", "XX", "XXX", "XXXX", |
| "XXXXX")</li> |
| <li>"+00" ("x")</li> |
| <li>"+0000" ("Z", "xx", "xxxx")</li> |
| <li>"+00:00" ("xxx", "xxxxx")</li> |
| </ul> |
| </li> |
| </ul> |
| <p><b>Note:</b> The digits in this case are always from the |
| western digits, 0..9.</p> |
| </li> |
| <li>For the non-location formats (generic or specific): |
| <ol> |
| <li>if there is an explicit translation for the TZID in |
| <timeZoneNames> according to type (generic, |
| standard, or daylight) in the resolved locale, return it. |
| <ol> |
| <li>If the requested type is not available, but |
| another type is, and there is a <strong>Type |
| Fallback</strong> then return that other type. |
| <ul> |
| <li>Examples: |
| <ul> |
| <li>America/Los_Angeles → // generic</li> |
| <li>America/Los_Angeles → "アメリカ太平洋標準時" // |
| standard</li> |
| <li>America/Los_Angeles → "Yhdysvaltain |
| Tyynenmeren kesäaika" // daylight</li> |
| <li>Europe/Dublin → "Am Samhraidh na |
| hÉireann" // daylight</li> |
| <li>Note: This translation may not at all be |
| literal: it would be what is most |
| recognizable for people using the target |
| language.</li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| </ol> |
| </li> |
| <li>Otherwise, get the requested metazone format |
| according to type (generic, standard, daylight). |
| <ol> |
| <li>If the requested type is not available, but |
| another type is, get the format according to |
| <strong>Type Fallback</strong>.</li> |
| <li>If there is no format for the type, fall |
| back.</li> |
| </ol> |
| </li> |
| <li>Otherwise do the following: |
| <ol> |
| <li>Get the country for the current locale. If there |
| is none, use the most likely country based on the |
| likelySubtags data. If there is none, use “001”.</li> |
| <li>Get the preferred zone for the metazone for the |
| country; if there is none for the country, use the |
| preferred zone for the metazone for “001”.</li> |
| <li>If that preferred zone is the same as the |
| requested zone, use the metazone format. For example, |
| "Pacific Time" for Vancouver if the locale is en_CA, |
| or for Los Angeles if locale is en_US.</li> |
| <li>Otherwise, if the zone is the preferred zone for |
| its country but not for the country of the locale, |
| use the metazone format + country in the |
| <em>fallbackFormat</em>.</li> |
| <li>Otherwise, use the metazone format + city in the |
| <em>fallbackFormat</em>. |
| <ul> |
| <li>Examples: |
| <ul> |
| <li>"Pacific Time (Canada)" // for the zone |
| Vancouver in the locale en_MX.</li> |
| <li>"Mountain Time (Phoenix)"</li> |
| <li>"Pacific Time (Whitehorse)"</li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| </ol> |
| </li> |
| </ol> |
| </li> |
| <li>For the generic location format: |
| <ol> |
| <li>From the TZDB get the country code for the zone, and |
| determine whether there is only one timezone in the |
| country. If there is only one timezone or if the zone id |
| is in the <primaryZones> list, format the country |
| name with the <em>regionFormat</em>, and return it. |
| <ul> |
| <li>Examples: |
| <ul> |
| <li>Europe/Rome → IT → "Italy Time" // for |
| English</li> |
| <li>Asia/Shanghai → CN → "China Time" // |
| Asia/Shanghai is the <em>primaryZone</em> for |
| China</li> |
| <li>Africa/Monrovia → LR → "Hora de Liberja"</li> |
| <li>America/Havana → CU → "Hora de CU" // if CU |
| is not localized</li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| <li>Otherwise format the exemplar city with the |
| <em>regionFormat</em>, and return it. |
| <ol> |
| <li>America/Buenos_Aires → "Buenos Aires Time"</li> |
| </ol> |
| </li> |
| </ol> |
| </li> |
| </ol> |
| <blockquote> |
| <p><strong>Note:</strong> If a language does require |
| grammatical changes when composing strings, then the |
| <em>regionFormat</em> should either use a neutral format such |
| as "Heure: {0}", or put all exceptional cases in explicitly |
| translated strings.</p> |
| </blockquote> |
| <p><strong>Type Fallback</strong></p> |
| <p>When a specified type (generic, standard, daylight) does not |
| exist:</p> |
| <ol> |
| <li>If the daylight type does not exist, then the metazone |
| doesn’t require daylight support. For all three types: |
| <ol> |
| <li>If the generic type exists, use it.</li> |
| <li>Otherwise if the standard type exists, use it.</li> |
| </ol> |
| </li> |
| <li>Otherwise if the generic type is needed, but not |
| available, and the offset and daylight offset do not change |
| within 184 day +/- interval around the exact formatted time, |
| use the standard type. |
| <ol> |
| <li>Example: "Mountain Standard Time" for Phoenix</li> |
| <li>Note: 184 is the smallest number that is at least 6 |
| months AND the smallest number that is more than 1/2 year |
| (Gregorian).</li> |
| </ol> |
| </li> |
| </ol> |
| <p><strong>Composition</strong></p> |
| <p>In composing the metazone + city or country:</p> |
| <ol> |
| <li>Use the <em>fallbackFormat</em> "{1} ({0})", where: |
| <ul> |
| <li>{1} will be the metazone</li> |
| <li>{0} will be a qualifier (city or country)</li> |
| <li>Example: |
| <ul> |
| <li>metazone = Pacific Time</li> |
| <li>city = Phoenix</li> |
| <li>→ "Pacific Time (Phoenix)"</li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| <li>If the localized country name is not available, use the |
| code: |
| <ul> |
| <li>CU (country code)→ "CU" <em>// no localized country |
| name for Cuba</em></li> |
| </ul> |
| </li> |
| <li>If the localized exemplar city is not available, use as |
| the exemplar city the last field of the raw TZID, stripping |
| off the prefix and turning _ into space. |
| <ul> |
| <li>America/Los_Angeles → "Los Angeles" <em>// no |
| localized exemplar city</em></li> |
| </ul> |
| </li> |
| </ol> |
| <p><b>Note:</b> As with the <em>regionFormat</em>, exceptional |
| cases need to be explicitly translated.</p> |
| <h3>7.3 <a name="Time_Zone_Parsing" href="#Time_Zone_Parsing" |
| id="Time_Zone_Parsing">Parsing</a></h3> |
| <p>In parsing, an implementation will be able to either |
| determine the zone id, or a simple offset from GMT for anything |
| formatting according to the above process.</p> |
| <p>The following is a sample process for how this might be |
| done. It is only a sample; implementations may use different |
| methods for parsing.</p> |
| <p>The sample describes the parsing of a zone as if it were an |
| isolated string. In implementations, the zone may be mixed in |
| with other data (like the time), so the parsing actually has to |
| look for the longest match, and then allow the remaining text |
| to be parsed for other content. That requires certain adaptions |
| to the following process.</p> |
| <ol style="background-color: rgb(255, 255, 255);"> |
| <li><font color="#000000">Start with a string S.</font></li> |
| <li> |
| <font color="#000000">If S matches ISO 8601 time zone |
| format, return it.</font> |
| <ul> |
| <li>For example, "-0800" (RFC 822), "-08:00" (ISO 8601) |
| => Etc/GMT+8</li> |
| </ul> |
| </li> |
| <li>If S matches the English or localized GMT format, return |
| the corresponding TZID |
| <ul> |
| <li>Matching should be lenient. Thus allow for the number |
| formats like: 03, 3, 330, 3:30, 33045 or 3:30:45. Allow |
| +, -, or nothing. Allow spaces after GMT, +/-, and before |
| number. Allow non-Latin numbers. Allow UTC or UT (per RFC |
| 788) as synonyms for GMT ("GMT", "UT", "UTC" are global |
| formats, always allowed in parsing regardless of |
| locale).</li> |
| <li>For example, "GMT+3" or "UT+3" or "HPG+3" => |
| Etc/GMT-3</li> |
| <li>When parsing, the absence of a numeric offset should |
| be interpreted as offset 0, whether in localized or |
| global formats. For example, "GMT" or "UT" or "UTC+0" or |
| "HPG" => Etc/GMT</li> |
| </ul> |
| </li> |
| <li> |
| <font color="#000000">If S matches the fallback format, |
| extract P = {0} [ie, the part in parens in the root format] |
| and N = {1}.<br> |
| If S does not match, set P = "" and N = S<br> |
| If N matches the region format, then M = {0} from that |
| format, otherwise M = N.</font> |
| <ul> |
| <li><font color="#000000">For example, "United States |
| (Los Angeles) Time" => N = "United States Time", M = |
| "United States", P = "Los Angeles".</font></li> |
| <li><font color="#000000">For example, "United States |
| Time" => N = "United States Time", M = "United |
| States", P = "".</font></li> |
| <li><font color="#000000">For example, "United States" |
| => N = M = "United States", P = "".</font></li> |
| </ul> |
| </li> |
| <li> |
| <font color="#000000">If P, N, or M is a localized country, |
| set C to that value. If C has only one zone, return |
| it.</font> |
| <ul> |
| <li><font color="#000000">For example, "Italy Time (xxx)" |
| or "xxx (Italy)" => Europe/Rome</font></li> |
| <li><font color="#000000">For example, "xxx (Canada)" or |
| "Canada Time (xxx)" => Sets C = CA and |
| continues</font></li> |
| </ul> |
| </li> |
| <li> |
| <font color="#000000">If P is a localized exemplar city |
| name (and not metazone), return it.</font> |
| <ul> |
| <li><font color="#000000">For example, "xxxx (Phoenix)" |
| or "Phoenix (xxx)" => America/Phoenix</font></li> |
| </ul> |
| </li> |
| <li> |
| <font color="#000000">If N, or M is a localized time zone |
| name (and not metazone), return it.</font> |
| <ul> |
| <li><font color="#000000">For example, "Pacific Standard |
| Time (xxx)" => "America/Los_Angeles" // this is only |
| if "Pacific Standard Time" is not a metazone |
| localization.</font></li> |
| </ul> |
| </li> |
| <li> |
| <font color="#000000">If N or M is a localized |
| metazone</font> |
| <ul> |
| <li><font color="#000000">If it corresponds to only one |
| TZID, return it.</font></li> |
| <li><font color="#000000">If C is set, look up the |
| Metazone + Country => TZID mapping, and return that |
| value if it exists</font></li> |
| <li><font color="#000000">Get the locale's language, and |
| get the default country from that. Look up the Metazone + |
| DefaultCountry => TZID mapping, and return that value |
| if it exists.</font></li> |
| <li><font color="#000000">Otherwise, lookup Metazone + |
| 001 => TZID and return it (that will always |
| exist)</font></li> |
| </ul> |
| </li> |
| <li><font color="#000000">If you get this far, return an |
| error.</font></li> |
| </ol> |
| <blockquote> |
| <p><b>Note:</b> This CLDR date parsing recommendation does |
| not fully handle all RFC 788 date/time formats, nor is it |
| intended to.</p> |
| </blockquote> |
| <p>Parsing can be more lenient than the above, allowing for |
| different spacing, punctuation, or other variation. A stricter |
| parse would check for consistency between the xxx portions |
| above and the rest, so "Pacific Standard Time (India)" would |
| give an error.</p> |
| <p>Using this process, a correct parse will roundtrip the |
| location format (VVVV) back to the canonical zoneid.</p> |
| <ul> |
| <li>Australia/ACT → Australia/Sydney → “Sydney (Australia)” → |
| Australia/Sydney</li> |
| </ul> |
| <p>The GMT formats (Z and ZZZZ) will return back an offset, and |
| thus lose the original canonical zone id.</p> |
| <ul> |
| <li>Australia/ACT → Australia/Sydney → "GMT+11:00" → |
| GMT+11</li> |
| </ul> |
| <p>The daylight and standard time formats, and the non-location |
| formats (z, zzzz, v, and vvvv) may either roundtrip back to the |
| original canonical zone id, to a zone in the same metazone that |
| time, or to just an offset, depending on the available |
| translation data. Thus:</p> |
| <ul> |
| <li>Australia/ACT → Australia/Sydney → "GMT+11:00" → |
| GMT+11</li> |
| <li>PST8PDT → America/Los_Angeles → “PST” → |
| America/Los_Angeles</li> |
| <li>America/Vancouver → “Pacific Time (Canada)” → |
| America/Vancouver</li> |
| </ul> |
| <h2>8 <a name="Date_Format_Patterns" href= |
| "#Date_Format_Patterns" id="Date_Format_Patterns">Date Format |
| Patterns</a></h2> |
| <p>A date pattern is a character string consisting of two types |
| of elements:</p> |
| <ul> |
| <li><em>Pattern fields</em>, which repeat a specific |
| <em>pattern character</em> one or more times. These fields |
| are replaced with date and time data from a calendar when |
| formatting, or used to generate data for a calendar when |
| parsing. Currently, A..Z and a..z are reserved for use as |
| pattern characters (unless they are quoted, see next item). |
| The pattern characters currently defined, and the meaning of |
| different fields lengths for then, are listed in the Date |
| Field Symbol Table below.</li> |
| <li>Literal text, which is output as-is when formatting, and |
| must closely match when parsing. Literal text can include: |
| <ul> |
| <li>Any characters other than A..Z and a..z, including |
| spaces and punctuation.</li> |
| <li>Any text between single vertical quotes ('xxxx'), |
| which may include A..Z and a..z as literal text.</li> |
| <li>Two adjacent single vertical quotes (''), which |
| represent a literal single quote, either inside or |
| outside quoted text.</li> |
| </ul> |
| </li> |
| </ul> |
| <p>The following are examples:</p> |
| <table border="1" cellpadding="0" cellspacing="0" style= |
| "border-style: solid; border-collapse: collapse"> |
| <caption> |
| <a name="Date_Format_Pattern_Examples" href= |
| "#Date_Format_Pattern_Examples" id= |
| "Date_Format_Pattern_Examples">Date Format Pattern |
| Examples</a> |
| </caption> |
| <tr> |
| <th width="50%">Pattern</th> |
| <th width="50%">Result (in a particular locale)</th> |
| </tr> |
| <tr> |
| <td width="50%">yyyy.MM.dd G 'at' HH:mm:ss zzz</td> |
| <td width="50%">1996.07.10 AD at 15:08:56 PDT</td> |
| </tr> |
| <tr> |
| <td width="50%">EEE, MMM d, ''yy</td> |
| <td width="50%">Wed, July 10, '96</td> |
| </tr> |
| <tr> |
| <td width="50%">h:mm a</td> |
| <td width="50%">12:08 PM</td> |
| </tr> |
| <tr> |
| <td width="50%">hh 'o''clock' a, zzzz</td> |
| <td width="50%">12 o'clock PM, Pacific Daylight Time</td> |
| </tr> |
| <tr> |
| <td width="50%">K:mm a, z</td> |
| <td width="50%">0:00 PM, PST</td> |
| </tr> |
| <tr> |
| <td width="50%">yyyyy.MMMM.dd GGG hh:mm aaa</td> |
| <td width="50%">01996.July.10 AD 12:08 PM</td> |
| </tr> |
| </table> |
| <p><i>When parsing using a pattern, a lenient parse should be |
| used; see <a href="#Parsing_Dates_Times">Parsing Dates and |
| Times</a>.</i></p> |
| <p class="dtd"><!ATTLIST pattern numbers CDATA #IMPLIED |
| ></p> |
| <p>The numbers attribute is used to indicate that numeric |
| quantities in the pattern are to be rendered using a numbering |
| system other than then default numbering system defined for the |
| given locale. The attribute can be in one of two forms. If the |
| alternate numbering system is intended to apply to ALL numeric |
| quantities in the pattern, then simply use the numbering system |
| ID as found in <a href= |
| "tr35-numbers.html#Numbering_Systems">Numbering Systems</a>. To |
| apply the alternate numbering system only to a single field, |
| the syntax "<letter>=<numberingSystem>" can be used |
| one or more times, separated by semicolons.</p> |
| <p class="xmlExample">Examples:<br> |
| <pattern numbers="hebr">dd/mm/yyyy</pattern><br> |
| <!-- Use Hebrew numerals to represent numbers in the Hebrew |
| calendar, where "latn" numbering system is the default |
| --><br> |
| <br> |
| <pattern numbers="y=hebr">dd/mm/yyyy</pattern><br> |
| <!-- Same as above, except that ONLY the year value would be |
| rendered in Hebrew --><br> |
| <br> |
| <pattern |
| numbers="d=thai;m=hans;y=deva">dd/mm/yyyy</pattern><br> |
| |
| <!-- Illustrates use of multiple numbering systems for a |
| single pattern. --></p><br> |
| <p><strong>Pattern fields and the Date Field Symbol |
| Table</strong></p> |
| <p>The Date Field Symbol Table below shows the pattern |
| characters (Sym.) and associated fields used in date patterns. |
| The length of the pattern field is related to the length and |
| style used to format the data item. For numeric-only fields, |
| the field length typically indicates the minimum number of |
| digits that should be used to display the value (zero-padding |
| as necessary). As an example using pattern character ‘H’ for |
| hour (24-hour cycle) and values 5 and 11, a field “H” should |
| produce formatted results “5” and “11” while a field “HH” |
| should produce formatted results “05” and “11”. For |
| alphanumeric fields (such as months) and alphabetic-only fields |
| (such as era names), the relationship between field length and |
| formatted result may be more complex. Typically this is as |
| follows:</p> |
| <table cellspacing="0" cellpadding="2" border="1"> |
| <tr> |
| <th>Pattern field<br> |
| length</th> |
| <th>Typical style,<br> |
| alphanumeric item</th> |
| <th>Typical style,<br> |
| alpha-only item</th> |
| </tr> |
| <tr> |
| <td>1</td> |
| <td>Numeric, 1-2 digits (e.g. M)</td> |
| <td rowspan="3">Abbreviated (e.g. E, EE, EEE)</td> |
| </tr> |
| <tr> |
| <td>2</td> |
| <td>Numeric, 2 digits (e.g. MM)</td> |
| </tr> |
| <tr> |
| <td>3</td> |
| <td>Abbreviated (e.g. MMM)</td> |
| </tr> |
| <tr> |
| <td>4</td> |
| <td colspan="2">Wide / Long / Full (e.g. MMMM, EEEE)</td> |
| </tr> |
| <tr> |
| <td>5</td> |
| <td colspan="2">Narrow (e.g. MMMMM, EEEEE)<br> |
| (The counter-intuitive use of 5 letters for this is forced |
| by backwards compatibility)</td> |
| </tr> |
| </table> |
| <p>Notes for the table below:</p> |
| <ul> |
| <li>Any sequence of pattern characters other than those |
| listed below is invalid. Invalid pattern fields should be |
| handled for formatting and parsing as described in <a href= |
| "tr35.html#Invalid_Patterns">Handling Invalid |
| Patterns</a>.</li> |
| <li>The examples in the table below are merely illustrative |
| and may not reflect current actual data.</li> |
| </ul> |
| <table cellspacing="0" cellpadding="2" border="1"> |
| <caption> |
| <a name="Date_Field_Symbol_Table" href= |
| "#Date_Field_Symbol_Table" id= |
| "Date_Field_Symbol_Table">Date Field Symbol Table</a> |
| </caption> |
| <tr> |
| <th>Field<br> |
| Type</th> |
| <th style="text-align: center">Sym.</th> |
| <th style="text-align: center">Field<br> |
| Patterns</th> |
| <th>Examples</th> |
| <th colspan="2">Description</th> |
| </tr> |
| <tr> |
| <th rowspan="3" style= |
| "vertical-align: top; text-align: left"><a name='dfst-era' |
| href='#dfst-era' id="dfst-era">era</a></th> |
| <td style="text-align: center; vertical-align: top" |
| rowspan="3">G</td> |
| <td style="text-align: center; vertical-align: top"> |
| G..GGG</td> |
| <td style="vertical-align: top; text-align: left">AD<br> |
| [variant: CE]</td> |
| <td style="width:130px">Abbreviated</td> |
| <td rowspan="3" style= |
| "vertical-align: top; text-align: left">Era name. Era |
| string for the current date.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| GGGG</td> |
| <td style="vertical-align: top; text-align: left">Anno |
| Domini<br> |
| [variant: Common Era]</td> |
| <td>Wide</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| GGGGG</td> |
| <td style="vertical-align: top; text-align: left">A</td> |
| <td>Narrow</td> |
| </tr> |
| <tr> |
| <th rowspan="15"><a name='dfst-year' href='#dfst-year' id= |
| "dfst-year">year</a><a name="Year_Length_Examples" id= |
| "Year_Length_Examples"></a></th> |
| <td rowspan="5" style="text-align: center">y</td> |
| <td style="text-align: center">y</td> |
| <td>2, 20, 201, 2017, 20173</td> |
| <td rowspan="5" colspan="2">Calendar year (numeric). In |
| most cases the length of the y field specifies the minimum |
| number of digits to display, zero-padded as necessary; more |
| digits will be displayed if needed to show the full year. |
| However, “yy” requests just the two low-order digits of the |
| year, zero-padded as necessary. For most use cases, “y” or |
| “yy” should be adequate.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">yy</td> |
| <td>02, 20, 01, 17, 73</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">yyy</td> |
| <td>002, 020, 201, 2017, 20173</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">yyyy</td> |
| <td>0002, 0020, 0201, 2017, 20173</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">yyyyy+</td> |
| <td>...</td> |
| </tr> |
| <tr> |
| <td rowspan="5" style="text-align: center">Y</td> |
| <td style="text-align: center">Y</td> |
| <td>2, 20, 201, 2017, 20173</td> |
| <td rowspan="5" colspan="2">Year in “Week of Year” based |
| calendars in which the year transition occurs on a week |
| boundary; may differ from calendar year ‘y’ near a year |
| transition. This numeric year designation is used in |
| conjunction with pattern character ‘w’ in the ISO year-week |
| calendar as defined by ISO 8601, but can be used in |
| non-Gregorian based calendar systems where week date |
| processing is desired. The field length is interpreted in |
| the same was as for ‘y’; that is, “yy” specifies use |
| of the two low-order year digits, while any other field |
| length specifies a minimum number of digits to |
| display.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">YY</td> |
| <td>02, 20, 01, 17, 73</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">YYY</td> |
| <td>002, 020, 201, 2017, 20173</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">YYYY</td> |
| <td>0002, 0020, 0201, 2017, 20173</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">YYYYY+</td> |
| <td>...</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">u</td> |
| <td style="text-align: center">u+</td> |
| <td>4601</td> |
| <td colspan="2">Extended year (numeric). This is a single |
| number designating the year of this calendar system, |
| encompassing all supra-year fields. For example, for the |
| Julian calendar system, year numbers are positive, with an |
| era of BCE or CE. An extended year value for the Julian |
| calendar system assigns positive values to CE years and |
| negative values to BCE years, with 1 BCE being year 0. For |
| ‘u’, all field lengths specify a minimum number of digits; |
| there is no special interpretation for “uu”.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top" |
| rowspan="3">U</td> |
| <td style="text-align: center; vertical-align: top"> |
| U..UUU</td> |
| <td style="vertical-align: top; text-align: left">甲子</td> |
| <td>Abbreviated</td> |
| <td rowspan="3" style= |
| "vertical-align: top; text-align: left">Cyclic year name. |
| Calendars such as the Chinese lunar calendar (and related |
| calendars) and the Hindu calendars use 60-year cycles of |
| year names. If the calendar does not provide cyclic year |
| name data, or if the year value to be formatted is out of |
| the range of years for which cyclic name data is provided, |
| then numeric formatting is used (behaves like 'y').<br> |
| Currently the data only provides abbreviated names, which |
| will be used for all requested name widths.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| UUUU</td> |
| <td style="vertical-align: top; text-align: left">甲子 [for |
| now]</td> |
| <td>Wide</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| UUUUU</td> |
| <td style="vertical-align: top; text-align: left">甲子 [for |
| now]</td> |
| <td>Narrow</td> |
| </tr> |
| <tr> |
| <td>r</td> |
| <td style="text-align: center; vertical-align: top">r+</td> |
| <td>2017</td> |
| <td colspan="2">Related Gregorian year (numeric). For |
| non-Gregorian calendars, this corresponds to the extended |
| Gregorian year in which the calendar’s year begins. Related |
| Gregorian years are often displayed, for example, when |
| formatting dates in the Japanese calendar — e.g. |
| “2012(平成24)年1月15日” — or in the Chinese calendar — e.g. |
| “2012壬辰年腊月初四”. The related Gregorian year is usually |
| displayed using the "latn" numbering system, regardless of |
| what numbering systems may be used for other parts of the |
| formatted date. If the calendar’s year is linked to the |
| solar year (perhaps using leap months), then for that |
| calendar the ‘r’ year will always be at a fixed offset from |
| the ‘u’ year. For the Gregorian calendar, the ‘r’ year is |
| the same as the ‘u’ year. For ‘r’, all field lengths |
| specify a minimum number of digits; there is no special |
| interpretation for “rr”.</td> |
| </tr> |
| <tr> |
| <th rowspan="10" style= |
| "vertical-align: top; text-align: left"><a name= |
| 'dfst-quarter' href='#dfst-quarter' id= |
| "dfst-quarter">quarter</a></th> |
| <td style="text-align: center; vertical-align: top" |
| rowspan="5">Q</td> |
| <td style="text-align: center; vertical-align: top">Q</td> |
| <td style="vertical-align: top; text-align: left">2</td> |
| <td>Numeric: 1 digit</td> |
| <td rowspan="5">Quarter number/name.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top">QQ</td> |
| <td style="vertical-align: top; text-align: left">02</td> |
| <td>Numeric: 2 digits + zero pad</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| QQQ</td> |
| <td style="vertical-align: top; text-align: left">Q2</td> |
| <td>Abbreviated</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| QQQQ</td> |
| <td style="vertical-align: top; text-align: left">2nd |
| quarter</td> |
| <td>Wide</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| QQQQQ</td> |
| <td style="vertical-align: top; text-align: left">2</td> |
| <td>Narrow</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top" |
| rowspan="5">q</td> |
| <td style="text-align: center; vertical-align: top">q</td> |
| <td style="vertical-align: top; text-align: left">2</td> |
| <td>Numeric: 1 digit</td> |
| <td rowspan="5" style= |
| "vertical-align: top; text-align: left"><b>Stand-Alone</b> |
| Quarter number/name.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top">qq</td> |
| <td style="vertical-align: top; text-align: left">02</td> |
| <td>Numeric: 2 digits + zero pad</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| qqq</td> |
| <td style="vertical-align: top; text-align: left">Q2</td> |
| <td>Abbreviated</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| qqqq</td> |
| <td style="vertical-align: top; text-align: left">2nd |
| quarter</td> |
| <td>Wide</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| qqqqq</td> |
| <td style="vertical-align: top; text-align: left">2</td> |
| <td>Narrow</td> |
| </tr> |
| <tr> |
| <th rowspan="11" style= |
| "vertical-align: top; text-align: left"><a name= |
| 'dfst-month' href='#dfst-month' id= |
| "dfst-month">month</a></th> |
| <td rowspan="5" style= |
| "text-align: center; vertical-align: top">M</td> |
| <td style="text-align: center; vertical-align: top">M</td> |
| <td>9, 12</td> |
| <td>Numeric: minimum digits</td> |
| <td rowspan="5" style= |
| "vertical-align: top; text-align: left">Month number/name, |
| format style (intended to be used in conjunction with ‘d’ |
| for day number).</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top">MM</td> |
| <td>09, 12</td> |
| <td>Numeric: 2 digits, zero pad if needed</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| MMM</td> |
| <td style="vertical-align: top; text-align: left">Sep</td> |
| <td>Abbreviated</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| MMMM</td> |
| <td style="vertical-align: top; text-align: left"> |
| September</td> |
| <td>Wide</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| MMMMM</td> |
| <td style="vertical-align: top; text-align: left">S</td> |
| <td>Narrow</td> |
| </tr> |
| <tr> |
| <td rowspan="5" style= |
| "text-align: center; vertical-align: top">L</td> |
| <td style="text-align: center; vertical-align: top">L</td> |
| <td>9, 12</td> |
| <td>Numeric: minimum digits</td> |
| <td rowspan="5"><b>Stand-Alone</b> Month number/name |
| (intended to be used without ‘d’ for day number).</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top">LL</td> |
| <td>09, 12</td> |
| <td>Numeric: 2 digits, zero pad if needed</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| LLL</td> |
| <td style="vertical-align: top; text-align: left">Sep</td> |
| <td>Abbreviated</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| LLLL</td> |
| <td style="vertical-align: top; text-align: left"> |
| September</td> |
| <td>Wide</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| LLLLL</td> |
| <td style="vertical-align: top; text-align: left">S</td> |
| <td>Narrow</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">l</td> |
| <td style="text-align: center">l</td> |
| <td>[nothing]</td> |
| <td colspan="2">This pattern character is deprecated, and |
| should be ignored in patterns. It was originally intended |
| to be used in combination with M to indicate placement of |
| the symbol for leap month in the Chinese calendar. |
| Placement of that marker is now specified using |
| locale-specific <monthPatterns> data, and formatting |
| and parsing of that marker should be handled as part of |
| supporting the regular M and L pattern characters.</td> |
| </tr> |
| <tr> |
| <th rowspan="3"><a name='dfst-week' href='#dfst-week' id= |
| "dfst-week">week</a></th> |
| <td rowspan="2" style="text-align: center">w</td> |
| <td style="text-align: center">w</td> |
| <td>8, 27</td> |
| <td>Numeric: minimum digits</td> |
| <td rowspan="2">Week of Year (numeric). When used in a |
| pattern with year, use ‘Y’ for the year field instead of |
| ‘y’.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top">ww</td> |
| <td>08, 27</td> |
| <td>Numeric: 2 digits, zero pad if needed</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">W</td> |
| <td style="text-align: center">W</td> |
| <td>3</td> |
| <td>Numeric: 1 digit</td> |
| <td>Week of Month (numeric)</td> |
| </tr> |
| <tr> |
| <th rowspan="5"><a name='dfst-day' href='#dfst-day' id= |
| "dfst-day">day</a></th> |
| <td rowspan="2" style="text-align: center">d</td> |
| <td style="text-align: center">d</td> |
| <td>1</td> |
| <td>Numeric: minimum digits</td> |
| <td rowspan="2">Day of month (numeric).</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">dd</td> |
| <td>01</td> |
| <td>Numeric: 2 digits, zero pad if needed</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">D</td> |
| <td style="text-align: center">D...DDD</td> |
| <td>345</td> |
| <td colspan="2">Day of year (numeric). The field length |
| specifies the minimum number of digits, with zero-padding |
| as necessary.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">F</td> |
| <td style="text-align: center">F</td> |
| <td>2</td> |
| <td colspan="2">Day of Week in Month (numeric). The example |
| is for the 2nd Wed in July</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">g</td> |
| <td style="text-align: center">g+</td> |
| <td>2451334</td> |
| <td colspan="2">Modified Julian day (numeric). This is |
| different from the conventional Julian day number in two |
| regards. First, it demarcates days at local zone midnight, |
| rather than noon GMT. Second, it is a local number; that |
| is, it depends on the local time zone. It can be thought of |
| as a single number that encompasses all the date-related |
| fields.The field length specifies the minimum number of |
| digits, with zero-padding as necessary.</td> |
| </tr> |
| <tr> |
| <th rowspan="15" style= |
| "vertical-align: top; text-align: left"><a name= |
| 'dfst-weekday' href='#dfst-weekday' id= |
| "dfst-weekday">week<br> |
| day</a></th> |
| <td rowspan="4" style= |
| "text-align: center; vertical-align: top">E</td> |
| <td style="text-align: center; vertical-align: top"> |
| E..EEE</td> |
| <td style="vertical-align: top; text-align: left">Tue</td> |
| <td>Abbreviated</td> |
| <td rowspan="4">Day of week name, format style.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| EEEE</td> |
| <td style="vertical-align: top; text-align: left"> |
| Tuesday</td> |
| <td>Wide</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| EEEEE</td> |
| <td style="vertical-align: top; text-align: left">T</td> |
| <td>Narrow</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| EEEEEE</td> |
| <td style="vertical-align: top; text-align: left">Tu</td> |
| <td>Short</td> |
| </tr> |
| <tr> |
| <td rowspan="6" style= |
| "text-align: center; vertical-align: top">e</td> |
| <td style="text-align: center; vertical-align: top">e</td> |
| <td style="vertical-align: top; text-align: left">2</td> |
| <td>Numeric: 1 digit</td> |
| <td rowspan="6" style= |
| "vertical-align: top; text-align: left">Local day of week |
| number/name, format style. Same as E except adds a numeric |
| value that will depend on the local starting day of the |
| week. For this example, Monday is the first day of the |
| week.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top">ee</td> |
| <td>02</td> |
| <td>Numeric: 2 digits + zero pad</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| eee</td> |
| <td style="vertical-align: top; text-align: left">Tue</td> |
| <td>Abbreviated</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| eeee</td> |
| <td style="vertical-align: top; text-align: left"> |
| Tuesday</td> |
| <td>Wide</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| eeeee</td> |
| <td style="vertical-align: top; text-align: left">T</td> |
| <td>Narrow</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| eeeeee</td> |
| <td style="vertical-align: top; text-align: left">Tu</td> |
| <td>Short</td> |
| </tr> |
| <tr> |
| <td rowspan="5" style= |
| "text-align: center; vertical-align: top">c</td> |
| <td style="text-align: center; vertical-align: top"> |
| c..cc</td> |
| <td style="vertical-align: top; text-align: left">2</td> |
| <td>Numeric: 1 digit</td> |
| <td rowspan="5"><b>Stand-Alone</b> local day of week |
| number/name.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| ccc</td> |
| <td style="vertical-align: top; text-align: left">Tue</td> |
| <td>Abbreviated</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| cccc</td> |
| <td style="vertical-align: top; text-align: left"> |
| Tuesday</td> |
| <td>Wide</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| ccccc</td> |
| <td style="vertical-align: top; text-align: left">T</td> |
| <td>Narrow</td> |
| </tr> |
| <tr> |
| <td style="text-align: center; vertical-align: top"> |
| cccccc</td> |
| <td style="vertical-align: top; text-align: left">Tu</td> |
| <td>Short</td> |
| </tr> |
| <tr> |
| <th rowspan="9"><a name='dfst-period' href='#dfst-period' |
| id="dfst-period">period</a></th> |
| <td rowspan="3" style="text-align: center">a</td> |
| <td style="text-align: center">a..aaa</td> |
| <td>am. [e.g. 12 am.]</td> |
| <td>Abbreviated</td> |
| <td rowspan="3"><strong>AM, PM<br></strong> May be upper or |
| lowercase depending on the locale and other options. The |
| wide form may be the same as the short form if the “real” |
| long form (eg <em>ante meridiem</em>) is not customarily |
| used. The narrow form must be unique, unlike some other |
| fields. See also Section 9 <a href= |
| "#Parsing_Dates_Times">Parsing Dates and Times</a>.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">aaaa</td> |
| <td>am. [e.g. 12 am.]</td> |
| <td>Wide</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">aaaaa</td> |
| <td>a [e.g. 12a]</td> |
| <td>Narrow</td> |
| </tr> |
| <tr> |
| <td rowspan="3" style="text-align: center">b</td> |
| <td style="text-align: center">b..bbb</td> |
| <td>mid. [e.g. 12 mid.]</td> |
| <td>Abbreviated</td> |
| <td rowspan="3"><strong>am, pm, noon, midnight</strong><br> |
| May be upper or lowercase depending on the locale and other |
| options. If the locale doesn't the notion of a unique |
| "noon" = 12:00, then the PM form may be substituted. |
| Similarly for "midnight" = 00:00 and the AM form. The |
| narrow form must be unique, unlike some other fields.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">bbbb</td> |
| <td>midnight<br> |
| [e.g. 12 midnight]</td> |
| <td>Wide</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">bbbbb</td> |
| <td>md [e.g. 12 md]</td> |
| <td>Narrow</td> |
| </tr> |
| <tr> |
| <td rowspan="3" style="text-align: center">B</td> |
| <td style="text-align: center">B..BBB</td> |
| <td>at night<br> |
| [e.g. 3:00 at night]</td> |
| <td>Abbreviated</td> |
| <td rowspan="3"><strong>flexible day periods</strong><br> |
| May be upper or lowercase depending on the locale and other |
| options. Often there is only one width that is customarily |
| used.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">BBBB</td> |
| <td>at night<br> |
| [e.g. 3:00 at night]</td> |
| <td>Wide</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">BBBBB</td> |
| <td>at night<br> |
| [e.g. 3:00 at night]</td> |
| <td>Narrow</td> |
| </tr> |
| <tr> |
| <th rowspan="22"><a name='dfst-hour' href='#dfst-hour' id= |
| "dfst-hour">hour</a></th> |
| <td rowspan="2" style="text-align: center">h</td> |
| <td style="text-align: center">h</td> |
| <td>1, 12</td> |
| <td>Numeric: minimum digits</td> |
| <td rowspan="2">Hour [1-12]. When used in skeleton data or |
| in a skeleton passed in an API for flexible date pattern |
| generation, it should match the 12-hour-cycle format |
| preferred by the locale (h or K); it should not match a |
| 24-hour-cycle format (H or k).</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">hh</td> |
| <td>01, 12</td> |
| <td>Numeric: 2 digits, zero pad if needed</td> |
| </tr> |
| <tr> |
| <td rowspan="2" style="text-align: center">H</td> |
| <td style="text-align: center">H</td> |
| <td>0, 23</td> |
| <td>Numeric: minimum digits</td> |
| <td rowspan="2">Hour [0-23]. When used in skeleton data or |
| in a skeleton passed in an API for flexible date pattern |
| generation, it should match the 24-hour-cycle format |
| preferred by the locale (H or k); it should not match a |
| 12-hour-cycle format (h or K).</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">HH</td> |
| <td>00, 23</td> |
| <td>Numeric: 2 digits, zero pad if needed</td> |
| </tr> |
| <tr> |
| <td rowspan="2" style="text-align: center">K</td> |
| <td style="text-align: center">K</td> |
| <td>0, 11</td> |
| <td>Numeric: minimum digits</td> |
| <td rowspan="2">Hour [0-11]. When used in a skeleton, only |
| matches K or h, see above.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">KK</td> |
| <td>00, 11</td> |
| <td>Numeric: 2 digits, zero pad if needed</td> |
| </tr> |
| <tr> |
| <td rowspan="2" style="text-align: center">k</td> |
| <td style="text-align: center">k</td> |
| <td>1, 24</td> |
| <td>Numeric: minimum digits</td> |
| <td rowspan="2">Hour [1-24]. When used in a skeleton, only |
| matches k or H, see above.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">kk</td> |
| <td>01, 24</td> |
| <td>Numeric: 2 digits, zero pad if needed</td> |
| </tr> |
| <tr> |
| <td rowspan="6" style="text-align: center">j</td> |
| <td>j</td> |
| <td>8<br> |
| 8 AM<br> |
| 13<br> |
| 1 PM</td> |
| <td>Numeric hour (minimum digits), abbreviated dayPeriod if |
| used</td> |
| <td rowspan="6"><em><strong>Input skeleton |
| symbol</strong></em><br> |
| It must not occur in pattern or skeleton data. Instead, it |
| is reserved for use in skeletons passed to APIs doing |
| flexible date pattern generation. In such a context, it |
| requests the preferred hour format for the locale (h, H, K, |
| or k), as determined by the <strong>preferred</strong> |
| attribute of the <strong>hours</strong> element in |
| supplemental data . In the implementation of such an API, |
| 'j' must be replaced by h, H, K, or k before beginning a |
| match against availableFormats data.<br> |
| Note that use of 'j' in a skeleton passed to an API is the |
| only way to have a skeleton request a locale's preferred |
| time cycle type (12-hour or 24-hour).</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">jj</td> |
| <td>08<br> |
| 08 AM<br> |
| 13<br> |
| 01 PM</td> |
| <td>Numeric hour (2 digits, zero pad if needed), |
| abbreviated dayPeriod if used</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">jjj</td> |
| <td>8<br> |
| 8 A.M.<br> |
| 13<br> |
| 1 P.M.</td> |
| <td>Numeric hour (minimum digits), wide dayPeriod if |
| used</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">jjjj</td> |
| <td>08<br> |
| 08 A.M.<br> |
| 13<br> |
| 01 P.M.</td> |
| <td>Numeric hour (2 digits, zero pad if needed), wide |
| dayPeriod if used</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">jjjjj</td> |
| <td>8<br> |
| 8a<br> |
| 13<br> |
| 1p</td> |
| <td>Numeric hour (minimum digits), narrow dayPeriod if |
| used</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">jjjjjj</td> |
| <td>08<br> |
| 08a<br> |
| 13<br> |
| 01p</td> |
| <td>Numeric hour (2 digits, zero pad if needed), narrow |
| dayPeriod if used</td> |
| </tr> |
| <tr> |
| <td rowspan="2" style="text-align: center">J</td> |
| <td style="text-align: center">J</td> |
| <td>8<br> |
| 8</td> |
| <td>Numeric hour (minimum digits)</td> |
| <td rowspan="2"><em><strong>Input skeleton |
| symbol</strong></em><br> |
| It must not occur in pattern or skeleton data. Instead, it |
| is reserved for use in skeletons passed to APIs doing |
| flexible date pattern generation. In such a context, like |
| 'j', it requests the preferred hour format for the locale |
| (h, H, K, or k), as determined by the |
| <strong>preferred</strong> attribute of the |
| <strong>hours</strong> element in supplemental data. |
| However, unlike 'j', it requests no dayPeriod marker such |
| as “am/pm” (It is typically used where there is enough |
| context that that is not necessary). For example, with |
| "jmm", 18:00 could appear as “6:00 PM”, while with "Jmm", |
| it would appear as “6:00” (no PM).</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">JJ</td> |
| <td>08<br> |
| 08</td> |
| <td>Numeric hour (2 digits, zero pad if needed)</td> |
| </tr> |
| <tr> |
| <td rowspan="6" style="text-align: center">C</td> |
| <td style="text-align: center">C</td> |
| <td>8<br> |
| 8 (morning)</td> |
| <td>Numeric hour (minimum digits), abbreviated dayPeriod if |
| used</td> |
| <td rowspan="6"><em><strong>Input skeleton |
| symbol</strong></em><br> |
| It must not occur in pattern or skeleton data. Instead, it |
| is reserved for use in skeletons passed to APIs doing |
| flexible date pattern generation. In such a context, like |
| 'j', it requests the preferred hour format for the locale. |
| However, unlike 'j', it can also select formats such as hb |
| or hB, since it is based not on the |
| <strong>preferred</strong> attribute of the |
| <strong>hours</strong> element in supplemental data, but |
| instead on the first element of the |
| <strong>allowed</strong> attribute (which is an ordered |
| preferrence list. For example, with "Cmm", 18:00 could |
| appear as “6:00 in the afternoon”.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">CC</td> |
| <td>08<br> |
| 08 (morning)</td> |
| <td>Numeric hour (2 digits, zero pad if needed), |
| abbreviated dayPeriod if used</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">CCC</td> |
| <td>8<br> |
| 8 in the morning</td> |
| <td>Numeric hour (minimum digits), wide dayPeriod if |
| used</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">CCCC</td> |
| <td>08<br> |
| 08 in the morning</td> |
| <td>Numeric hour (2 digits, zero pad if needed), wide |
| dayPeriod if used</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">CCCCC</td> |
| <td>8<br> |
| 8 (morn.)</td> |
| <td>Numeric hour (minimum digits), narrow dayPeriod if |
| used</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">CCCCCC</td> |
| <td>08<br> |
| 08 (morn.)</td> |
| <td>Numeric hour (2 digits, zero pad if needed), narrow |
| dayPeriod if used</td> |
| </tr> |
| <tr> |
| <th rowspan="2"><a name='dfst-minute' href='#dfst-minute' |
| id="dfst-minute">minute</a></th> |
| <td rowspan="2" style="text-align: center">m</td> |
| <td style="text-align: center">m</td> |
| <td>8, 59</td> |
| <td>Numeric: minimum digits</td> |
| <td rowspan="2">Minute (numeric). Truncated, not |
| rounded.<br></td> |
| </tr> |
| <tr> |
| <td style="text-align: center">mm</td> |
| <td>08, 59</td> |
| <td>Numeric: 2 digits, zero pad if needed</td> |
| </tr> |
| <tr> |
| <th rowspan="4"><a name='dfst-second' href='#dfst-second' |
| id="dfst-second">second</a></th> |
| <td rowspan="2" style="text-align: center">s</td> |
| <td style="text-align: center">s</td> |
| <td>8, 12</td> |
| <td>Numeric: minimum digits</td> |
| <td rowspan="2">Second (numeric). Truncated, not |
| rounded.<br></td> |
| </tr> |
| <tr> |
| <td style="text-align: center">ss</td> |
| <td>08, 12</td> |
| <td>Numeric: 2 digits, zero pad if needed</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">S</td> |
| <td style="text-align: center">S+</td> |
| <td>3456</td> |
| <td colspan="2">Fractional Second (numeric). Truncates, |
| like other numeric time fields, but in this case to the |
| number of digits specified by the field length. (Example |
| shows display using pattern SSSS for seconds value |
| 12.34567)</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">A</td> |
| <td style="text-align: center">A+</td> |
| <td>69540000</td> |
| <td colspan="2">Milliseconds in day (numeric). This field |
| behaves <i>exactly</i> like a composite of all time-related |
| fields, not including the zone fields. As such, it also |
| reflects discontinuities of those fields on DST transition |
| days. On a day of DST onset, it will jump forward. On a day |
| of DST cessation, it will jump backward. This reflects the |
| fact that is must be combined with the offset field to |
| obtain a unique local time value. The field length |
| specifies the minimum number of digits, with zero-padding |
| as necessary.</td> |
| </tr> |
| <tr> |
| <th><a name='dfst-sep' href='#dfst-sep' id= |
| "dfst-sep">sep.</a></th> |
| <td>(none def., see note)</td> |
| <td style="text-align: center"></td> |
| <td></td> |
| <td colspan="2">Time separator.<br> |
| <span class="note"><b><br> |
| Note:</b> In CLDR 26 the time separator pattern character |
| was specified to be COLON. This was withdrawn in CLDR 28 |
| due to backward compatibility issues, and no time separator |
| pattern character is currently defined.</span><br> |
| <br> |
| Like the use of "," in number formats, this character in a |
| date pattern is replaced with the corresponding number |
| symbol which may depend on the numbering system. For more |
| information, see <em><strong>Part 3: <a href= |
| "tr35-numbers.html#Contents">Numbers</a></strong> , Section |
| 2.3 <a href="tr35-numbers.html#Number_Symbols">Number |
| Symbols</a></em>.</td> |
| </tr> |
| <tr> |
| <th rowspan="23"><a name='dfst-zone' href='#dfst-zone' id= |
| "dfst-zone">zone</a></th> |
| <td rowspan="2" style="text-align: center">z</td> |
| <td style="text-align: center">z..zzz</td> |
| <td>PDT</td> |
| <td colspan="2">The <i>short specific non-location |
| format</i>. Where that is unavailable, falls back to the |
| <i>short localized GMT format</i> ("O").</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">zzzz</td> |
| <td>Pacific Daylight Time</td> |
| <td colspan="2">The <i>long specific non-location |
| format</i>. Where that is unavailable, falls back to the |
| <i>long localized GMT format</i> ("OOOO").</td> |
| </tr> |
| <tr> |
| <td rowspan="3" style="text-align: center">Z</td> |
| <td style="text-align: center">Z..ZZZ</td> |
| <td>-0800</td> |
| <td colspan="2">The <i>ISO8601 basic format</i> with hours, |
| minutes and optional seconds fields. The format is |
| equivalent to RFC 822 zone format (when optional seconds |
| field is absent). This is equivalent to the "xxxx" |
| specifier.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">ZZZZ</td> |
| <td>GMT-8:00</td> |
| <td colspan="2">The <i>long localized GMT format</i>. This |
| is equivalent to the "OOOO" specifier.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">ZZZZZ</td> |
| <td>-08:00<br> |
| -07:52:58</td> |
| <td colspan="2">The <i>ISO8601 extended format</i> with |
| hours, minutes and optional seconds fields. The ISO8601 UTC |
| indicator "Z" is used when local time offset is 0. This is |
| equivalent to the "XXXXX" specifier.</td> |
| </tr> |
| <tr> |
| <td rowspan="2" style="text-align: center">O</td> |
| <td style="text-align: center">O</td> |
| <td>GMT-8</td> |
| <td colspan="2">The <i>short localized GMT format</i>.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">OOOO</td> |
| <td>GMT-08:00</td> |
| <td colspan="2">The <i>long localized GMT format</i>.</td> |
| </tr> |
| <tr> |
| <td rowspan="2" style="text-align: center">v</td> |
| <td style="text-align: center">v</td> |
| <td>PT</td> |
| <td colspan="2">The <i>short generic non-location |
| format</i>. Where that is unavailable, falls back to the |
| <i>generic location format</i> ("VVVV"), then the <i>short |
| localized GMT format</i> as the final fallback.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">vvvv</td> |
| <td>Pacific Time</td> |
| <td colspan="2">The <i>long generic non-location |
| format</i>. Where that is unavailable, falls back to |
| <i>generic location format</i> ("VVVV").</td> |
| </tr> |
| <tr> |
| <td rowspan="4" style="text-align: center">V</td> |
| <td style="text-align: center">V</td> |
| <td>uslax</td> |
| <td colspan="2">The short time zone ID. Where that is |
| unavailable, the special short time zone ID <i>unk</i> |
| (Unknown Zone) is used.<br> |
| <i><b>Note</b>: This specifier was originally used for a |
| variant of the short specific non-location format, but it |
| was deprecated in the later version of this specification. |
| In CLDR 23, the definition of the specifier was changed to |
| designate a short time zone ID.</i></td> |
| </tr> |
| <tr> |
| <td style="text-align: center">VV</td> |
| <td>America/Los_Angeles</td> |
| <td colspan="2">The long time zone ID.</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">VVV</td> |
| <td>Los Angeles</td> |
| <td colspan="2">The exemplar city (location) for the time |
| zone. Where that is unavailable, the localized exemplar |
| city name for the special zone <i>Etc/Unknown</i> is used |
| as the fallback (for example, "Unknown City").</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">VVVV</td> |
| <td>Los Angeles Time</td> |
| <td colspan="2">The <i>generic location format</i>. Where |
| that is unavailable, falls back to the <i>long localized |
| GMT format</i> ("OOOO"; Note: Fallback is only necessary |
| with a GMT-style Time Zone ID, like Etc/GMT-830.)<br> |
| This is especially useful when presenting possible timezone |
| choices for user selection, since the naming is more |
| uniform than the "v" format.</td> |
| </tr> |
| <tr> |
| <td rowspan="5" style="text-align: center">X</td> |
| <td style="text-align: center">X</td> |
| <td>-08<br> |
| +0530<br> |
| Z</td> |
| <td colspan="2">The <i>ISO8601 basic format</i> with hours |
| field and optional minutes field. The ISO8601 UTC indicator |
| "Z" is used when local time offset is 0. (The same as x, |
| plus "Z".)</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">XX</td> |
| <td>-0800<br> |
| Z</td> |
| <td colspan="2">The <i>ISO8601 basic format</i> with hours |
| and minutes fields. The ISO8601 UTC indicator "Z" is used |
| when local time offset is 0. (The same as xx, plus |
| "Z".)</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">XXX</td> |
| <td>-08:00<br> |
| Z</td> |
| <td colspan="2">The <i>ISO8601 extended format</i> with |
| hours and minutes fields. The ISO8601 UTC indicator "Z" is |
| used when local time offset is 0. (The same as xxx, plus |
| "Z".)</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">XXXX</td> |
| <td>-0800<br> |
| -075258<br> |
| Z</td> |
| <td colspan="2">The <i>ISO8601 basic format</i> with hours, |
| minutes and optional seconds fields. The ISO8601 UTC |
| indicator "Z" is used when local time offset is 0. (The |
| same as xxxx, plus "Z".)<br> |
| <i><b>Note</b>: The seconds field is not supported by the |
| ISO8601 specification.</i></td> |
| </tr> |
| <tr> |
| <td style="text-align: center">XXXXX</td> |
| <td>-08:00<br> |
| -07:52:58<br> |
| Z</td> |
| <td colspan="2">The <i>ISO8601 extended format</i> with |
| hours, minutes and optional seconds fields. The ISO8601 UTC |
| indicator "Z" is used when local time offset is 0. (The |
| same as xxxxx, plus "Z".)<br> |
| <i><b>Note</b>: The seconds field is not supported by the |
| ISO8601 specification.</i></td> |
| </tr> |
| <tr> |
| <td rowspan="5" style="text-align: center">x</td> |
| <td style="text-align: center">x</td> |
| <td>-08<br> |
| +0530<br> |
| +00</td> |
| <td colspan="2">The <i>ISO8601 basic format</i> with hours |
| field and optional minutes field. (The same as X, minus |
| "Z".)</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">xx</td> |
| <td>-0800<br> |
| +0000</td> |
| <td colspan="2">The <i>ISO8601 basic format</i> with hours |
| and minutes fields. (The same as XX, minus "Z".)</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">xxx</td> |
| <td>-08:00<br> |
| +00:00</td> |
| <td colspan="2">The <i>ISO8601 extended format</i> with |
| hours and minutes fields. (The same as XXX, minus |
| "Z".)</td> |
| </tr> |
| <tr> |
| <td style="text-align: center">xxxx</td> |
| <td>-0800<br> |
| -075258<br> |
| +0000</td> |
| <td colspan="2">The <i>ISO8601 basic format</i> with hours, |
| minutes and optional seconds fields. (The same as XXXX, |
| minus "Z".)<br> |
| <i><b>Note</b>: The seconds field is not supported by the |
| ISO8601 specification.</i></td> |
| </tr> |
| <tr> |
| <td style="text-align: center">xxxxx</td> |
| <td>-08:00<br> |
| -07:52:58<br> |
| +00:00</td> |
| <td colspan="2">The <i>ISO8601 extended format</i> with |
| hours, minutes and optional seconds fields. (The same as |
| XXXXX, minus "Z".)<br> |
| <i><b>Note</b>: The seconds field is not supported by the |
| ISO8601 specification.</i></td> |
| </tr> |
| </table> |
| <h3>8.1 <a name="Localized_Pattern_Characters" href= |
| "#Localized_Pattern_Characters" id= |
| "Localized_Pattern_Characters">Localized Pattern Characters |
| (deprecated)</a></h3> |
| <p>These are characters that can be used when displaying a date |
| pattern to an end user. This can occur, for example, when a |
| spreadsheet allows users to specify date patterns. Whatever is |
| in the string is substituted one-for-one with the characters |
| "GyMdkHmsSEDFwWahKzYeugAZvcLQqVUOXxr", with the above meanings. |
| Thus, for example, if 'J' is to be used instead of 'Y' to mean |
| Year (for Week of Year), then the string would be: |
| "GyMdkHmsSEDFwWahKz<u>J</u>eugAZvcLQqVUOXxr".</p> |
| <p>This element is deprecated. It is recommended instead that a |
| more sophisticated UI be used for localization, such as using |
| icons to represent the different formats (and lengths) in the |
| <a href="#Date_Field_Symbol_Table">Date Field Symbol |
| Table</a>.</p> |
| <h3>8.2 <a name="Date_Patterns_AM_PM" href= |
| "#Date_Patterns_AM_PM" id="Date_Patterns_AM_PM">AM / |
| PM</a></h3> |
| <p>Even for countries where the customary date format only has |
| a 24 hour format, both the am and pm localized strings must be |
| present and must be distinct from one another. Note that as |
| long as the 24 hour format is used, these strings will normally |
| never be used, but for testing and unusual circumstances they |
| must be present.</p> |
| <h3>8.3 <a name="Date_Patterns_Eras" href="#Date_Patterns_Eras" |
| id="Date_Patterns_Eras">Eras</a></h3> |
| <p>There are only two values for era in the Gregorian calendar, |
| with two common naming conventions (here in abbreviated form |
| for English): "BC" and "AD", or "BCE" and "CE". These values |
| can be translated into other languages, like "a.C." and and |
| "d.C." for Spanish, but there are no other eras in the |
| Gregorian calendar. Other calendars have a different numbers of |
| eras. Care should be taken when translating the era names for a |
| specific calendar.</p> |
| <h3>8.4 <a name="Date_Patterns_Week_Of_Year" href= |
| "#Date_Patterns_Week_Of_Year" id= |
| "Date_Patterns_Week_Of_Year">Week of Year</a></h3> |
| <p>Values calculated for the Week of Year field range from 1 to |
| 53 for the Gregorian calendar (they may have different ranges |
| for other calendars). Week 1 for a year is the first week that |
| contains at least the specified minimum number of days from |
| that year. Weeks between week 1 of one year and week 1 of the |
| following year are numbered sequentially from 2 to 52 or 53 (if |
| needed). For example, January 1, 1998 was a Thursday. If the |
| first day of the week is MONDAY and the minimum days in a week |
| is 4 (these are the values reflecting ISO 8601 and many |
| national standards), then week 1 of 1998 starts on December 29, |
| 1997, and ends on January 4, 1998. However, if the first day of |
| the week is SUNDAY, then week 1 of 1998 starts on January 4, |
| 1998, and ends on January 10, 1998. The first three days of |
| 1998 are then part of week 53 of 1997.</p> |
| <p>Values are similarly calculated for the Week of Month.</p> |
| <h3>8.5 <a name="Date_Patterns_Week_Elements" href= |
| "#Date_Patterns_Week_Elements" id= |
| "Date_Patterns_Week_Elements">Week Elements</a></h3> |
| <dl> |
| <dt><b>firstDay</b></dt> |
| <dd>A number indicating which day of the week is considered |
| the 'first' day, for calendar purposes. Because the ordering |
| of days may vary between calendar, keywords are used for this |
| value, such as sun, mon, …. These values will be replaced by |
| the localized name when they are actually used.</dd> |
| <dt><b>minDays (Minimal Days in First Week)</b></dt> |
| <dd>Minimal days required in the first week of a month or |
| year. For example, if the first week is defined as one that |
| contains at least one day, this value will be 1. If it must |
| contain a full seven days before it counts as the first week, |
| then the value would be 7.</dd> |
| <dt><b>weekendStart, weekendEnd</b></dt> |
| <dd>Indicates the day and time that the weekend starts or |
| ends. As with firstDay, keywords are used instead of |
| numbers.</dd> |
| </dl> |
| <h2>9 <a name="Parsing_Dates_Times" href="#Parsing_Dates_Times" |
| id="Parsing_Dates_Times">Parsing Dates and Times</a></h2> |
| <p>For general information on lenient parsing, see <a href= |
| "tr35.html#Lenient_Parsing">Lenient Parsing</a> in the core |
| specification. This section provides additional information |
| specific to parsing of dates and times.</p> |
| <p>Lenient parsing of date and time strings is especially |
| complicated, due to the large number of possible fields and |
| formats. The fields fall into two categories: numeric fields |
| (hour, day of month, year, numeric month, and so on) and |
| symbolic fields (era, quarter, month, weekday, AM/PM, time |
| zone). In addition, the user may type in a date or time in a |
| form that is significantly different from the normal format for |
| the locale, and the application must use the locale information |
| to figure out what the user meant. Input may well consist of |
| nothing but a string of numbers with separators, for example, |
| "09/05/02 09:57:33".</p> |
| <p>The input can be separated into tokens: numbers, symbols, |
| and literal strings. Some care must be taken due to ambiguity, |
| for example, in the Japanese locale the symbol for March is "3 |
| 月", which looks like a number followed by a literal. To avoid |
| these problems, symbols should be checked first, and spaces |
| should be ignored (except to delimit the tokens of the input |
| string).</p> |
| <p>The meaning of symbol fields should be easy to determine; |
| the problem is determining the meaning of the numeric fields. |
| Disambiguation will likely be most successful if it is based on |
| heuristics. Here are some rules that can help:</p> |
| <ul> |
| <li>Always try the format string expected for the input text |
| first. This is the only way to disambiguate 03/07 (March |
| 2007, a credit card expiration date) from 03/07 (March 7, a |
| birthday).</li> |
| <li>Attempt to match fields and literals against those in the |
| format string, using loose matching of the tokens. In |
| particular, Unicode normalization and case variants should be |
| accepted. Alternate symbols can also be accepted where |
| unambiguous: for example, “11.30 am”.</li> |
| <li>When matching symbols, try the narrow, abbreviated, and |
| full-width forms, including standalone forms if they are |
| unique. You may want to allow prefix matches too, or |
| diacritic-insensitive, again, as long as they are unique. For |
| example, for a month, accept 9, 09, S, Se, Sep, Sept, Sept., |
| and so on. For abbreviated symbols (e.g. names of eras, |
| months, weekdays), allow matches both with and without an |
| abbreviation marker such as period (or whatever else may be |
| customary in the locale); abbreviated forms in the CLDR data |
| may or may not have such a marker. |
| <ul> |
| <li>Note: While parsing of narrow date values (e.g. month |
| or day names) may be required in order to obtain minimum |
| information from a formatted date (for instance, the only |
| month information may be in a narrow form), the results |
| are not guaranteed; parsing of an ambiguous formatted |
| date string may produce a result that differs from the |
| date originally used to create the formatted string.</li> |
| <li>For day periods, ASCII variants for AM/PM such as |
| “am”, “a.m.”, “am.” (and their case variants) should be |
| accepted, since they are widely used as alternates to |
| native formats.</li> |
| </ul> |
| </li> |
| <li>When a field or literal is encountered that is not |
| compatible with the pattern: |
| <ul> |
| <li>Synchronization is not necessary for symbolic fields, |
| since they are self-identifying. Wait until a numeric |
| field or literal is encountered before attempting to |
| resynchronize.</li> |
| <li>Ignore whether the input token is symbolic or |
| numeric, if it is compatible with the current field in |
| the pattern.</li> |
| <li>Look forward or backward in the current format string |
| for a literal that matches the one most recently |
| encountered. See if you can resynchronize from that |
| point. Use the value of the numeric field to |
| resynchronize as well, if possible (for example, a number |
| larger than the largest month cannot be a month)</li> |
| <li>If that fails, use other format strings from the |
| locale (including those in <availableFormats>) to |
| try to match the previous or next symbol or literal |
| (again, using a loose match).</li> |
| </ul> |
| </li> |
| </ul> |
| <hr> |
| <p class="copyright">Copyright © 2001–2019 Unicode, Inc. All |
| Rights Reserved. The Unicode Consortium makes no expressed or |
| implied warranty of any kind, and assumes no liability for |
| errors or omissions. No liability is assumed for incidental and |
| consequential damages in connection with or arising out of the |
| use of the information or programs contained or accompanying |
| this technical report. The Unicode <a href= |
| "http://unicode.org/copyright.html">Terms of Use</a> apply.</p> |
| <p class="copyright">Unicode and the Unicode logo are |
| trademarks of Unicode, Inc., and are registered in some |
| jurisdictions.</p> |
| </div> |
| </body> |
| </html> |
