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