Html程序
|
4797行
|
198.23 KB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<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 style="text-align: center">
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>34</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 -->
<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">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">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">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">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">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">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">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">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">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 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">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">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">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">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 hour character
used in the locale's standard short time format. 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">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">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">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">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">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">Supplemental Calendar Data</a>
</h2>
<h3>
4.1 <a name="Calendar_Data" href="#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">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">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">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">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">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">Day
Period Rules</a>
</h4>
<p>Here are the requirements for a rule set.</p>
<h5>
<a name="Fixed_periods" href="#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">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">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">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"><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">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">Supplemental Time Zone Data</a>
</h2>
<h3>
6.1 <a name="Metazones" href="#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">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">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">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">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"><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">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">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">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">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">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'>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'>year</a><a name="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'>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'>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'>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'>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'>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'>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'>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'>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'>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'>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'>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">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">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">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">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">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">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–2018 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>