1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 2"https://www.w3.org/TR/html4/loose.dtd"> 3<html> 4<head> 5 <meta name="generator" content= 6 "HTML Tidy for HTML5 for Apple macOS version 5.6.0"> 7 <meta http-equiv="Content-Type" content= 8 "text/html; charset=utf-8"> 9 <meta http-equiv="Content-Language" content="en-us"> 10 <link rel="stylesheet" href= 11 "../reports.css" type="text/css"> 12 <title>UTS #35: Unicode LDML: Dates</title> 13 <style type="text/css"> 14 <!-- 15 .dtd { 16 font-family: monospace; 17 font-size: 90%; 18 background-color: #CCCCFF; 19 border-style: dotted; 20 border-width: 1px; 21 } 22 23 .xmlExample { 24 font-family: monospace; 25 font-size: 80% 26 } 27 28 .blockedInherited { 29 font-style: italic; 30 font-weight: bold; 31 border-style: dashed; 32 border-width: 1px; 33 background-color: #FF0000 34 } 35 36 .inherited { 37 font-weight: bold; 38 border-style: dashed; 39 border-width: 1px; 40 background-color: #00FF00 41 } 42 43 .element { 44 font-weight: bold; 45 color: red; 46 } 47 48 .attribute { 49 font-weight: bold; 50 color: maroon; 51 } 52 53 .attributeValue { 54 font-weight: bold; 55 color: blue; 56 } 57 58 li, p { 59 margin-top: 0.5em; 60 margin-bottom: 0.5em 61 } 62 63 h2, h3, h4, table { 64 margin-top: 1.5em; 65 margin-bottom: 0.5em; 66 } 67 --> 68 </style> 69</head> 70<body> 71 <table class="header" width="100%"> 72 <tr> 73 <td class="icon"><a href="https://unicode.org"><img alt= 74 "[Unicode]" src="../logo60s2.gif" 75 width="34" height="33" style= 76 "vertical-align: middle; border-left-width: 0px; border-bottom-width: 0px; border-right-width: 0px; border-top-width: 0px;"></a> 77 <a class="bar" href= 78 "https://www.unicode.org/reports/">Technical Reports</a></td> 79 </tr> 80 <tr> 81 <td class="gray"> </td> 82 </tr> 83 </table> 84 <div class="body"> 85 <h2 style="text-align: center">Unicode Technical Standard #35</h2> 86 <h1>Unicode Locale Data Markup Language (LDML)<br> 87 Part 4: Dates</h1> 88 <!-- At least the first row of this header table should be identical across the parts of this UTS. --> 89 <table border="1" cellpadding="2" cellspacing="0" class="wide"> 90 <tr> 91 <td>Version</td> 92 <td>38</td> 93 </tr> 94 <tr> 95 <td>Editors</td> 96 <td>Peter Edberg and <a href= 97 "tr35.html#Acknowledgments">other CLDR committee 98 members</a></td> 99 </tr> 100 </table> 101 <p>For the full header, summary, and status, see <a href= 102 "tr35.html">Part 1: Core.</a></p> 103 <h3><i>Summary</i></h3> 104 <p>This document describes parts of an XML format 105 (<i>vocabulary</i>) for the exchange of structured locale data. 106 This format is used in the <a href= 107 "https://unicode.org/cldr/">Unicode Common Locale Data 108 Repository</a>.</p> 109 <p>This is a partial document, describing only those parts of 110 the LDML that are relevant for date, time, and time zone 111 formatting. For the other parts of the LDML see the <a href= 112 "tr35.html">main LDML document</a> and the links above.</p> 113 <h3><i>Status</i></h3> 114 115 <!-- NOT YET APPROVED 116 <p> 117 <i class="changed">This is a<b><font color="#ff3333"> 118 draft </font></b>document which may be updated, replaced, or superseded by 119 other documents at any time. Publication does not imply endorsement 120 by the Unicode Consortium. This is not a stable document; it is 121 inappropriate to cite this document as other than a work in 122 progress. 123 </i> 124 </p> 125 END NOT YET APPROVED --> 126 <!-- APPROVED --> 127 <p><i>This document has been reviewed by Unicode members and 128 other interested parties, and has been approved for publication 129 by the Unicode Consortium. This is a stable document and may be 130 used as reference material or cited as a normative reference by 131 other specifications.</i></p> 132 <!-- END APPROVED --> 133 134 <blockquote> 135 <p><i><b>A Unicode Technical Standard (UTS)</b> is an 136 independent specification. Conformance to the Unicode 137 Standard does not imply conformance to any UTS.</i></p> 138 </blockquote> 139 <p><i>Please submit corrigenda and other comments with the CLDR 140 bug reporting form [<a href="tr35.html#Bugs">Bugs</a>]. Related 141 information that is useful in understanding this document is 142 found in the <a href="tr35.html#References">References</a>. For 143 the latest version of the Unicode Standard see [<a href= 144 "tr35.html#Unicode">Unicode</a>]. For a list of current Unicode 145 Technical Reports see [<a href= 146 "tr35.html#Reports">Reports</a>]. For more information about 147 versions of the Unicode Standard, see [<a href= 148 "tr35.html#Versions">Versions</a>].</i></p> 149 <!-- This section of Parts should be identical in all of the parts of this UTS. --> 150 <h2><a name="Parts" href="#Parts" id="Parts">Parts</a></h2> 151 <p>The LDML specification is divided into the following 152 parts:</p> 153 <ul class="toc"> 154 <li>Part 1: <a href="tr35.html#Contents">Core</a> (languages, 155 locales, basic structure)</li> 156 <li>Part 2: <a href="tr35-general.html#Contents">General</a> 157 (display names & transforms, etc.)</li> 158 <li>Part 3: <a href="tr35-numbers.html#Contents">Numbers</a> 159 (number & currency formatting)</li> 160 <li>Part 4: <a href="tr35-dates.html#Contents">Dates</a> 161 (date, time, time zone formatting)</li> 162 <li>Part 5: <a href= 163 "tr35-collation.html#Contents">Collation</a> (sorting, 164 searching, grouping)</li> 165 <li>Part 6: <a href= 166 "tr35-info.html#Contents">Supplemental</a> (supplemental 167 data)</li> 168 <li>Part 7: <a href= 169 "tr35-keyboards.html#Contents">Keyboards</a> (keyboard 170 mappings)</li> 171 </ul> 172 <h2><a name="Contents" href="#Contents" id="Contents">Contents 173 of Part 4, Dates</a></h2> 174 <!-- START Generated TOC: CheckHtmlFiles --> 175 <ul class="toc"> 176 <li>1 <a href= 177 "#Overview_Dates_Element_Supplemental">Overview: Dates 178 Element, Supplemental Date and Calendar Information</a></li> 179 <li>2 <a href="#Calendar_Elements">Calendar Elements</a> 180 <ul class="toc"> 181 <li>2.1 <a href="#months_days_quarters_eras">Elements 182 months, days, quarters, eras</a></li> 183 <li>2.2 <a href="#monthPatterns_cyclicNameSets">Elements 184 monthPatterns, cyclicNameSets</a></li> 185 <li>2.3 <a href="#dayPeriods">Element dayPeriods</a></li> 186 <li>2.4 <a href="#dateFormats">Element 187 dateFormats</a></li> 188 <li>2.5 <a href="#timeFormats">Element 189 timeFormats</a></li> 190 <li>2.6 <a href="#dateTimeFormats">Element 191 dateTimeFormats</a> 192 <ul class="toc"> 193 <li>2.6.1 <a href="#dateTimeFormat">Element 194 dateTimeFormat</a> 195 <ul class="toc"> 196 <li>Table: <a href= 197 "#Date_Time_Combination_Examples">Date-Time 198 Combination Examples</a></li> 199 </ul> 200 </li> 201 <li>2.6.2 <a href= 202 "#availableFormats_appendItems">Elements 203 availableFormats, appendItems</a> 204 <ul class="toc"> 205 <li>2.6.2.1 <a href= 206 "#Matching_Skeletons">Matching Skeletons</a></li> 207 <li>2.6.2.2 <a href= 208 "#Missing_Skeleton_Fields">Missing Skeleton 209 Fields</a></li> 210 </ul> 211 </li> 212 <li>2.6.3 <a href="#intervalFormats">Element 213 intervalFormats</a></li> 214 </ul> 215 </li> 216 </ul> 217 </li> 218 <li>3 <a href="#Calendar_Fields">Calendar Fields</a></li> 219 <li>4 <a href="#Supplemental_Calendar_Data">Supplemental 220 Calendar Data</a> 221 <ul class="toc"> 222 <li>4.1 <a href="#Calendar_Data">Calendar Data</a></li> 223 <li>4.2 <a href="#Calendar_Preference_Data">Calendar 224 Preference Data</a></li> 225 <li>4.3 <a href="#Week_Data">Week Data</a></li> 226 <li>4.4 <a href="#Time_Data">Time Data</a></li> 227 <li>4.5 <a href="#Day_Period_Rule_Sets">Day Period Rule 228 Sets</a> 229 <ul class="toc"> 230 <li>4.5.1 <a href="#Day_Period_Rules">Day Period 231 Rules</a> 232 <ul class="toc"> 233 <li>4.5.1.1 <a href="#Fixed_periods">Fixed 234 periods</a></li> 235 <li>4.5.1.2 <a href="#Variable_periods">Variable 236 periods</a></li> 237 <li>4.5.1.3 <a href= 238 "#Parsing_Day_Periods">Parsing Day 239 Periods</a></li> 240 </ul> 241 </li> 242 </ul> 243 </li> 244 </ul> 245 </li> 246 <li>5 <a href="#Time_Zone_Names">Time Zone Names</a> 247 <ul class="toc"> 248 <li>Table: <a href= 249 "#timeZoneNames_Elements_Used_for_Fallback"><timeZoneNames> 250 Elements Used for Fallback</a></li> 251 <li>5.1 <a href="#Metazone_Names">Metazone Names</a></li> 252 </ul> 253 </li> 254 <li>6 <a href="#Supplemental_Time_Zone_Data">Supplemental 255 Time Zone Data</a> 256 <ul class="toc"> 257 <li>6.1 <a href="#Metazones">Metazones</a></li> 258 <li>6.2 <a href="#Windows_Zones">Windows Zones</a></li> 259 <li>6.3 <a href="#Primary_Zones">Primary Zones</a></li> 260 </ul> 261 </li> 262 <li>7 <a href="#Using_Time_Zone_Names">Using Time Zone 263 Names</a> 264 <ul class="toc"> 265 <li>7.1 <a href="#Time_Zone_Format_Terminology">Time Zone 266 Format Terminology</a></li> 267 <li>7.2 <a href="#Time_Zone_Goals">Goals</a></li> 268 <li>7.3 <a href="#Time_Zone_Parsing">Parsing</a></li> 269 </ul> 270 </li> 271 <li>8 <a href="#Date_Format_Patterns">Date Format 272 Patterns</a> 273 <ul class="toc"> 274 <li>Table: <a href="#Date_Format_Pattern_Examples">Date 275 Format Pattern Examples</a></li> 276 <li><a href="#Date_Field_Symbol_Table">Date Field Symbol 277 Table</a></li> 278 <li>8.1 <a href="#Localized_Pattern_Characters">Localized 279 Pattern Characters (deprecated)</a></li> 280 <li>8.2 <a href="#Date_Patterns_AM_PM">AM / PM</a></li> 281 <li>8.3 <a href="#Date_Patterns_Eras">Eras</a></li> 282 <li>8.4 <a href="#Date_Patterns_Week_Of_Year">Week of 283 Year</a></li> 284 <li>8.5 <a href="#Date_Patterns_Week_Elements">Week 285 Elements</a></li> 286 </ul> 287 </li> 288 <li>9 <a href="#Parsing_Dates_Times">Parsing Dates and 289 Times</a></li> 290 </ul><!-- END Generated TOC: CheckHtmlFiles --> 291 <h2>1 <a name="Overview_Dates_Element_Supplemental" href= 292 "#Overview_Dates_Element_Supplemental" id= 293 "Overview_Dates_Element_Supplemental">Overview: Dates Element, 294 Supplemental Date and Calendar Information</a></h2> 295 <p class="dtd"><!ELEMENT dates (alias | (calendars?, 296 fields?, timeZoneNames?, special*)) ></p> 297 <p>The LDML top-level <dates> element contains 298 information regarding the format and parsing of dates and 299 times, the formatting of date/time intervals, and the the 300 naming of various calendar elements.</p> 301 <ul> 302 <li>The <calendars> element is described in section 2 303 <a href="#Calendar_Elements">Calendar Elements</a>.</li> 304 <li>The <fields> element is described in section 3 305 <a href="#Calendar_Fields">Calendar Fields</a>.</li> 306 <li>The <timeZoneNames> element is described in section 307 5 <a href="#Time_Zone_Names">Time Zone Names</a>.</li> 308 <li>The formats use pattern characters described in section 8 309 <a href="#Date_Format_Patterns">Date Format 310 Patterns</a>.</li> 311 </ul> 312 <p class="dtd"><!ELEMENT supplementalData ( …, 313 calendarData?, calendarPreferenceData?, weekData?, timeData?, 314 …, timezoneData?, …, metazoneInfo?, …, dayPeriodRuleSet*, 315 metaZones?, primaryZones?, windowsZones?, …) ></p> 316 <p>The relevant top-level supplemental elements are listed 317 above.</p> 318 <ul> 319 <li>The <calendarData>, <calendarPreferenceData>, 320 <weekData>, <timeData>, and 321 <dayPeriodRuleSet> elements are described in section 4 322 <a href="#Supplemental_Calendar_Data">Supplemental Calendar 323 Data</a>.</li> 324 <li>The <timezoneData> element is deprecated and no 325 longer used; the <metazoneInfo> element is deprecated 326 at this level, and is now only used as a sub-element of 327 <metaZones>.</li> 328 <li>The <metaZones>, <primaryZones>, and 329 <windowsZones> elements are described in section 6 330 <a href="#Supplemental_Time_Zone_Data">Supplemental Time Zone 331 Data</a>.</li> 332 </ul> 333 <h2>2 <a name="Calendar_Elements" href="#Calendar_Elements" id= 334 "Calendar_Elements">Calendar Elements</a></h2> 335 <p class="dtd"><!ELEMENT calendars (alias | (calendar*, 336 special*)) ><br> 337 <!ELEMENT calendar (alias | (months?, monthPatterns?, days?, 338 quarters?, dayPeriods?, eras?, cyclicNameSets?, dateFormats?, 339 timeFormats?, dateTimeFormats?, special*))><br> 340 <!ATTLIST calendar type NMTOKEN #REQUIRED ></p> 341 <p>The <calendars> element contains multiple 342 <calendar> elements, each of which specifies the fields 343 used for formatting and parsing dates and times according to 344 the calendar specified by the type attribute (e.g. "gregorian", 345 "buddhist", "islamic"). The behaviors for different calendars 346 in a locale may share certain aspects, such as the names for 347 weekdays. They differ in other respects; for example, the 348 Japanese calendar is similar to the Gregorian calendar but has 349 many more eras (one for each Emperor), and years are numbered 350 within each era. All calendar data inherits either from the 351 Gregorian calendar or other calendars in the same locale (and 352 if not present there then from the parent up to root), or else 353 inherits directly from the parent locale for certain calendars, 354 so only data that differs from what would be inherited needs to 355 be supplied. See <i><a href= 356 "tr35.html#Multiple_Inheritance">Multiple 357 Inheritance</a></i>.</p> 358 <p>Each calendar provides—directly or indirectly—two general 359 types of data:</p> 360 <ul> 361 <li><em>Calendar symbols, such as names for eras, months, 362 weekdays, and dayPeriods.</em> Names for weekdays, quarters 363 and dayPeriods are typically inherited from the Gregorian 364 calendar data in the same locale. Symbols for eras and months 365 should be provided for each calendar, except that the 366 "Gregorian-like" Buddhist, Japanese, and Minguo (ROC) 367 calendars also inherit their month names from the Gregorian 368 data in the same locale.</li> 369 <li><em>Format data for dates, times, and date-time 370 intervals.</em> Non-Gregorian calendars inherit standard time 371 formats (in the <timeFormats> element) from the 372 Gregorian calendar in the same locale. Most non-Gregorian 373 calendars (other than Chinese and Dangi) inherit general date 374 format data (in the <dateFormats> and 375 <dateTimeFormats> elements) from the "generic" calendar 376 format data in the same locale, which in turn inherits from 377 Gregorian.</li> 378 </ul> 379 <p>Calendars that use cyclicNameSets and monthPatterns (such as 380 Chinese and Dangi) have additional symbols and distinct 381 formats, and typically inherit these items (along with month 382 names) from their parent locales, instead of inheriting them 383 from Gregorian or generic data in the same locale.</p> 384 <p>The primary difference between Gregorian and "generic" 385 format data is that date formats in "generic" usually include 386 era with year, in order to provide an indication of which 387 calendar is being used (Gregorian calendar formats may also 388 commonly include era with year when Gregorian is not the 389 default calendar for the locale). Otherwise, the "generic" date 390 formats should normally be consistent with those in the 391 Gregorian calendar. The "generic" calendar formats are intended 392 to provide a consistent set of default formats for 393 non-Gregorian calendars in the locale, so that in most cases 394 the only data items that need be provided for non-Gregorian 395 calendars are the era names and month names (and the latter 396 only for calendars other than Buddhist, Japanese, and Minguo, 397 since those inherit month names from Gregorian).</p> 398 <h3>2.1 <a name="months_days_quarters_eras" href= 399 "#months_days_quarters_eras" id= 400 "months_days_quarters_eras">Elements months, days, quarters, 401 eras</a></h3> 402 <p class="dtd"><!ELEMENT months ( alias | (monthContext*, 403 special*)) ><br> 404 <!ELEMENT monthContext ( alias | (default*, monthWidth*, 405 special*)) ><br> 406 <!ATTLIST monthContext type ( format | stand-alone ) 407 #REQUIRED ><br> 408 <!ELEMENT monthWidth ( alias | (month*, special*)) ><br> 409 <!ATTLIST monthWidth type ( abbreviated| narrow | wide) 410 #REQUIRED ><br> 411 <!ELEMENT month ( #PCDATA )* ><br> 412 <!ATTLIST month type ( 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 413 10 | 11 | 12 | 13 ) #REQUIRED ><br> 414 <!ATTLIST month yeartype ( standard | leap ) #IMPLIED 415 ></p> 416 <p class="dtd"><!ELEMENT days ( alias | (dayContext*, 417 special*)) ><br> 418 <!ELEMENT dayContext ( alias | (default*, dayWidth*, 419 special*)) ><br> 420 <!ATTLIST dayContext type ( format | stand-alone ) #REQUIRED 421 ><br> 422 <!ELEMENT dayWidth ( alias | (day*, special*)) ><br> 423 <!ATTLIST dayWidth type NMTOKEN #REQUIRED ><br> 424 <!ELEMENT day ( #PCDATA ) ><br> 425 <!ATTLIST day type ( sun | mon | tue | wed | thu | fri | sat 426 ) #REQUIRED ></p> 427 <p class="dtd"><!ELEMENT quarters ( alias | 428 (quarterContext*, special*)) ><br> 429 <!ELEMENT quarterContext ( alias | (default*, quarterWidth*, 430 special*)) ><br> 431 <!ATTLIST quarterContext type ( format | stand-alone ) 432 #REQUIRED ><br> 433 <!ELEMENT quarterWidth ( alias | (quarter*, special*)) 434 ><br> 435 <!ATTLIST quarterWidth type NMTOKEN #REQUIRED ><br> 436 <!ELEMENT quarter ( #PCDATA ) ><br> 437 <!ATTLIST quarter type ( 1 | 2 | 3 | 4 ) #REQUIRED ></p> 438 <p class="dtd"><!ELEMENT eras (alias | (eraNames?, eraAbbr?, 439 eraNarrow?, special*)) ><br> 440 <!ELEMENT eraNames ( alias | (era*, special*) ) ><br> 441 <!ELEMENT eraAbbr ( alias | (era*, special*) ) ><br> 442 <!ELEMENT eraNarrow ( alias | (era*, special*) ) 443 ><br></p> 444 <p>The month and quarter names are identified numerically, 445 starting at 1. The weekday names are identified with short 446 strings, since there is no universally-accepted numeric 447 designation.</p> 448 <p>Month, day, and quarter names may vary along two axes: the 449 width and the context.</p> 450 <p>The context is either <i>format</i> (the default), the form 451 used within a complete date format string (such as "Saturday, 452 November 12"), or <i>stand-alone</i>, the form for date 453 elements used independently, such as in calendar headers. The 454 most important distinction between format and stand-alone 455 forms is a grammatical distinction, for languages that require 456 it. For example, many languages require that a month name 457 without an associated day number (i.e. an independent form) be 458 in the basic <i>nominative</i> form, while a month name with 459 an associated day number (as in a complete date format) should 460 be in a different grammatical form: <i>genitive</i>, 461 <i>partitive</i>, etc. In past versions of CLDR, the 462 distinction between format and stand-alone forms was also used 463 to control capitalization (with stand-alone forms using 464 titlecase); however, this can be controlled separately and more 465 precisely using the <contextTransforms> element as 466 described in <i><a href= 467 "tr35-general.html#Context_Transform_Elements">ContextTransform 468 Elements</a></i>, so stand-alone forms should generally use 469 middle-of-sentence capitalization. However, if in a given 470 language, certain context/width combinations are always used in 471 a titlecase form — for example, stand-alone narrow forms for 472 months or weekdays — then these should be provided in that 473 form.</p> 474 <p>The width can be <i>wide</i> (the default), 475 <i>abbreviated</i>, or <i>narrow</i>; for days only, the width 476 can also be <i>short,</i> which is ideally between the 477 abbreviated and narrow widths, but must be no longer than 478 abbreviated and no shorter than narrow (if short day names are 479 not explicitly specified, abbreviated day names are used 480 instead). Note that for <monthPattern>, described in the 481 next section:</p> 482 <ul> 483 <li>There is an additional context type <i>numeric</i></li> 484 <li>When the context type is numeric, the width has a special 485 type <i>all</i></li> 486 </ul> 487 <p>The format values must be distinct for the wide, 488 abbreviated, and short widths. However, values for the narrow 489 width in either format or stand-alone contexts, as well as 490 values for other widths in stand-alone contexts, need not be 491 distinct; they might only be distinguished by context. For 492 example, "S" may be used both for Saturday and for Sunday. The 493 narrow width is typically used in calendar headers; it must be 494 the shortest possible width, no more than one character (or 495 grapheme cluster, or exemplar set element) in stand-alone 496 values (not including punctuation), and the shortest possible 497 widths (in terms of grapheme clusters) in format values. The 498 short width (if present) is often the shortest unambiguous 499 form.</p> 500 <p>Era names should be distinct within each of the widths, 501 including narrow; there is less disambiguating information for 502 them, and they are more likely to be used in a format that 503 requires parsing.</p> 504 <p>Due to aliases in root, the forms inherit "sideways". (See 505 <i><a href="tr35.html#Multiple_Inheritance">Multiple 506 Inheritance</a></i>.) For example, if the abbreviated format 507 data for Gregorian does not exist in a language X (in the chain 508 up to root), then it inherits from the wide format data in that 509 same language X.</p> 510 <pre id="line369"><monthContext type="format"> 511 <monthWidth type="abbreviated"> 512 <alias source="locale" path="../monthWidth[@type='wide']"/> 513 </monthWidth> 514 <monthWidth type="narrow"> 515 <alias source="locale" path="../../monthContext[@type='<b>stand-alone</b>']/monthWidth[@type='narrow']"/> 516 </monthWidth> 517 <monthWidth type="wide"> 518 <month type="1">1</month> 519 ... 520 <month type="12">12</month> 521 </monthWidth> 522</monthContext> 523<monthContext type="stand-alone"> 524 <monthWidth type="abbreviated"> 525 <alias source="locale" path="../../monthContext[@type='<b>format</b>']/monthWidth[@type='abbreviated']"/> 526 </monthWidth> 527 <monthWidth type="narrow"> 528 <month type="1">1</month> 529 ... 530 <month type="12">12</month> 531 </monthWidth> 532 <monthWidth type="wide"> 533 <alias source="locale" path="../../monthContext[@type='<b>format</b>']/monthWidth[@type='wide']"/> 534 </monthWidth> 535</monthContext></pre> 536 <p>The yeartype attribute for months is used to distinguish 537 alternate month names that would be displayed for certain 538 calendars during leap years. The practical example of this 539 usage occurs in the Hebrew calendar, where the 7th month "Adar" 540 occurs in non-leap years, with the 6th month being skipped, but 541 in leap years there are two months named "Adar I" and "Adar 542 II". There are currently only two defined year types, standard 543 (the implied default) and leap.</p> 544 <p>For era elements, an additional alt="variant" form may be 545 supplied. This is primarily intended for use in the "gregorian" 546 calendar, with which two parallel sets of era designations are 547 used in some locales: one set with a religious reference (e.g. 548 English BC/AD), and one set without (e.g. English BCE/CE). The 549 most commonly-used set for the locale should be provided as the 550 default, and the other set may be provided as the alt="variant" 551 forms. See the example below.</p> 552 <p class="example">Example:</p> 553 <pre> <calendar type="<span style= 554 "color: blue">gregorian</span>"> 555 <months> 556 <monthContext type="<span style= 557"color: blue">format</span>"> 558 <monthWidth type="<span style= 559"color: blue">wide</span>"> 560 <month type="<span style= 561"color: blue">1</span>"><span style= 562"color: blue">January</span></month> 563 <month type="<span style= 564"color: blue">2</span>"><span style= 565"color: blue">February</span></month> 566... 567 <month type="<span style= 568"color: blue">11</span>"><span style= 569"color: blue">November</span></month> 570 <month type="<span style= 571"color: blue">12</span>"><span style= 572"color: blue">December</span></month> 573 </monthWidth> 574 <monthWidth type="<span style= 575"color: blue">abbreviated</span>"> 576 <month type="<span style= 577"color: blue">1</span>"><span style= 578"color: blue">Jan</span></month> 579 <month type="<span style= 580"color: blue">2</span>"><span style= 581"color: blue">Feb</span></month> 582... 583 <month type="<span style= 584"color: blue">11</span>"><span style= 585"color: blue">Nov</span></month> 586 <month type="<span style= 587"color: blue">12</span>"><span style= 588"color: blue">Dec</span></month> 589 </monthWidth> 590 <monthContext type="<span style= 591"color: blue">stand-alone</span>"> 592 <default type="<span style= 593"color: blue">wide</span>"/> 594 <monthWidth type="<span style= 595"color: blue">wide</span>"> 596 <month type="<span style= 597"color: blue">1</span>"><span style= 598"color: blue">Januaria</span></month> 599 <month type="<span style= 600"color: blue">2</span>"><span style= 601"color: blue">Februaria</span></month> 602... 603 <month type="<span style= 604"color: blue">11</span>"><span style= 605"color: blue">Novembria</span></month> 606 <month type="<span style= 607"color: blue">12</span>"><span style= 608"color: blue">Decembria</span></month> 609 </monthWidth> 610 <monthWidth type="<span style= 611"color: blue">narrow</span>"> 612 <month type="<span style= 613"color: blue">1</span>"><span style= 614"color: blue">J</span></month> 615 <month type="<span style= 616"color: blue">2</span>"><span style= 617"color: blue">F</span></month> 618... 619 <month type="<span style= 620"color: blue">11</span>"><span style= 621"color: blue">N</span></month> 622 <month type="<span style= 623"color: blue">12</span>"><span style= 624"color: blue">D</span></month> 625 </monthWidth> 626 </monthContext> 627 </months> 628 629 <days> 630 <dayContext type="<span style= 631"color: blue">format</span>"> 632 <dayWidth type="<span style= 633"color: blue">wide</span>"> 634 <day type="<span style= 635"color: blue">sun</span>"><span style= 636"color: blue">Sunday</span></day> 637 <day type="<span style= 638"color: blue">mon</span>"><span style= 639"color: blue">Monday</span></day> 640... 641 <day type="<span style= 642"color: blue">fri</span>"><span style= 643"color: blue">Friday</span></day> 644 <day type="<span style= 645"color: blue">sat</span>"><span style= 646"color: blue">Saturday</span></day> 647 </dayWidth> 648 <dayWidth type="<span style= 649"color: blue">abbreviated</span>"> 650 <day type="<span style= 651"color: blue">sun</span>"><span style= 652"color: blue">Sun</span></day> 653 <day type="<span style= 654"color: blue">mon</span>"><span style= 655"color: blue">Mon</span></day> 656... 657 <day type="<span style= 658"color: blue">fri</span>"><span style= 659"color: blue">Fri</span></day> 660 <day type="<span style= 661"color: blue">sat</span>"><span style= 662"color: blue">Sat</span></day> 663 </dayWidth> 664 <dayWidth type="<span style= 665"color: blue">narrow</span>"> 666 <day type="<span style= 667"color: blue">sun</span>"><span style= 668"color: blue">Su</span></day> 669 <day type="<span style= 670"color: blue">mon</span>"><span style= 671"color: blue">M</span></day> 672... 673 <day type="<span style= 674"color: blue">fri</span>"><span style= 675"color: blue">F</span></day> 676 <day type="<span style= 677"color: blue">sat</span>"><span style= 678"color: blue">Sa</span></day> 679 </dayWidth> 680 </dayContext> 681 <dayContext type="<span style= 682"color: blue">stand-alone</span>"> 683 <dayWidth type="<span style= 684"color: blue">narrow</span>"> 685 <day type="<span style= 686"color: blue">sun</span>"><span style= 687"color: blue">S</span></day> 688 <day type="<span style= 689"color: blue">mon</span>"><span style= 690"color: blue">M</span></day> 691... 692 <day type="<span style= 693"color: blue">fri</span>"><span style= 694"color: blue">F</span></day> 695 <day type="<span style= 696"color: blue">sat</span>"><span style= 697"color: blue">S</span></day> 698 </dayWidth> 699 </dayContext> 700 </days> 701 702 <quarters> 703 <quarterContext type="<span style= 704"color: blue">format</span>"> 705 <quarterWidth type="<span style= 706"color: blue">abbreviated</span>"> 707 <quarter type="<span style= 708"color: blue">1</span>"><span style= 709"color: blue">Q1</span></quarter> 710 <quarter type="<span style= 711"color: blue">2</span>"><span style= 712"color: blue">Q2</span></quarter> 713 <quarter type="<span style= 714"color: blue">3</span>"><span style= 715"color: blue">Q3</span></quarter> 716 <quarter type="<span style= 717"color: blue">4</span>"><span style= 718"color: blue">Q4</span></quarter> 719 </quarterWidth> 720 <quarterWidth type="<span style= 721"color: blue">wide</span>"> 722 <quarter type="<span style= 723"color: blue">1</span>"><span style= 724"color: blue">1st quarter</span></quarter> 725 <quarter type="<span style= 726"color: blue">2</span>"><span style= 727"color: blue">2nd quarter</span></quarter> 728 <quarter type="<span style= 729"color: blue">3</span>"><span style= 730"color: blue">3rd quarter</span></quarter> 731 <quarter type="<span style= 732"color: blue">4</span>"><span style= 733"color: blue">4th quarter</span></quarter> 734 </quarterWidth> 735 </quarterContext> 736 </quarters> 737 738 <eras> 739 <eraAbbr> 740 <era type="<span style= 741"color: blue">0</span>"><span style= 742"color: blue">BC</span></era> 743 <era type="<span style= 744"color: blue">0</span>" alt="<span style= 745"color: blue">variant</span>"><span style= 746"color: blue">BCE</span></era> 747 <era type="<span style= 748"color: blue">1</span>"><span style= 749"color: blue">AD</span></era> 750 <era type="<span style= 751"color: blue">1</span>" alt="<span style= 752"color: blue">variant</span>"><span style= 753"color: blue">CE</span></era> 754 </eraAbbr> 755 <eraNames> 756 <era type="<span style= 757"color: blue">0</span>"><span style= 758"color: blue">Before Christ</span></era> 759 <era type="<span style= 760"color: blue">0</span>" alt="<span style= 761"color: blue">variant</span>"><span style= 762"color: blue">Before Common Era</span></era> 763 <era type="<span style= 764"color: blue">1</span>"><span style= 765"color: blue">Anno Domini</span></era> 766 <era type="<span style= 767"color: blue">1</span>" alt="<span style= 768"color: blue">variant</span>"><span style= 769"color: blue">Common Era</span></era> 770 </eraNames> 771 <eraNarrow> 772 <era type="<span style= 773"color: blue">0</span>"><span style= 774"color: blue">B</span></era> 775 <era type="<span style= 776"color: blue">1</span>"><span style= 777"color: blue">A</span></era> 778 </eraNarrow> 779 </eras> 780</pre> 781 <h3>2.2 <a name="monthPatterns_cyclicNameSets" href= 782 "#monthPatterns_cyclicNameSets" id= 783 "monthPatterns_cyclicNameSets">Elements monthPatterns, 784 cyclicNameSets</a></h3> 785 <p class="dtd"><!ELEMENT monthPatterns ( alias | 786 (monthPatternContext*, special*)) ><br> 787 <!ELEMENT monthPatternContext ( alias | (monthPatternWidth*, 788 special*)) ><br> 789 <!ATTLIST monthPatternContext type ( format | stand-alone | 790 numeric ) #REQUIRED ><br> 791 <!ELEMENT monthPatternWidth ( alias | (monthPattern*, 792 special*)) ><br> 793 <!ATTLIST monthPatternWidth type ( abbreviated| narrow | 794 wide | all ) #REQUIRED ><br> 795 <!ELEMENT monthPattern ( #PCDATA ) ><br> 796 <!ATTLIST monthPattern type ( leap | standardAfterLeap | 797 combined ) #REQUIRED ><br></p> 798 <p class="dtd"><!ELEMENT cyclicNameSets ( alias | 799 (cyclicNameSet*, special*)) ><br> 800 <!ELEMENT cyclicNameSet ( alias | (cyclicNameContext*, 801 special*)) ><br> 802 <!ATTLIST cyclicNameSet type ( years | months | days | 803 dayParts | zodiacs | solarTerms ) #REQUIRED ><br> 804 <!ELEMENT cyclicNameContext ( alias | (cyclicNameWidth*, 805 special*)) ><br> 806 <!ATTLIST cyclicNameContext type ( format | stand-alone ) 807 #REQUIRED ><br> 808 <!ELEMENT cyclicNameWidth ( alias | (cyclicName*, special*)) 809 ><br> 810 <!ATTLIST cyclicNameWidth type ( abbreviated | narrow | wide 811 ) #REQUIRED ><br> 812 <!ELEMENT cyclicName ( #PCDATA ) ><br> 813 <!ATTLIST cyclicName type NMTOKEN #REQUIRED ><br></p> 814 <p>The Chinese lunar calendar can insert a leap month after 815 nearly any month of its year; when this happens, the month 816 takes the name of the preceding month plus a special marker. 817 The Hindu lunar calendars can insert a leap month before any 818 one or two months of the year; when this happens, not only does 819 the leap month take the name of the following month plus a 820 special marker, the following month also takes a special 821 marker. Moreover, in the Hindu calendar sometimes a month is 822 skipped, in which case the preceding month takes a special 823 marker plus the names of both months. The <monthPatterns> 824 element structure supports these special kinds of month names. 825 It parallels the <months> element structure, with various 826 contexts and widths, but with some differences:</p> 827 <ul> 828 <li>Since the month markers may be applied to numeric months 829 as well, there is an additional monthPatternContext type 830 "numeric" for this case. When the numeric context is used, 831 there is no need for different widths, so the 832 monthPatternWidth type is "all" for this case.</li> 833 <li>The monthPattern element itself is a pattern showing how 834 to create the modified month name from the standard month 835 name(s). The three types of possible pattern are for "leap", 836 "standardAfterLeap", and "combined".</li> 837 <li>The <monthPatterns> element is not present for 838 calendars that do not need it.</li> 839 </ul> 840 <p>The Chinese and Hindu lunar calendars also use a 60-name 841 cycle for designating years. The Chinese lunar calendars can 842 also use that cycle for months and days, and can use 12-name 843 cycles for designating day subdivisions or zodiac names 844 associated with years; a 24-name cycle of solar terms (12 pairs 845 of minor and major terms) is used to mark intervals in the 846 solar cycle. The <cyclicNameSets> element structure 847 supports these special kinds of name cycles; a cyclicNameSet 848 can be provided for types "year", "month", "day", "dayParts", 849 or "zodiacs". For each cyclicNameSet, there is a context and 850 width structure similar to that for day names. For a given 851 context and width, a set of cyclicName elements provides the 852 actual names.</p> 853 <p>Example:</p> 854 <pre> 855 <monthPatterns> 856 <monthPatternContext type="format"> 857 <monthPatternWidth type="wide"> 858 <monthPattern type="leap">闰{0}</monthPattern> 859 </monthPatternWidth> 860 </monthPatternContext> 861 <monthPatternContext type="stand-alone"> 862 <monthPatternWidth type="narrow"> 863 <monthPattern type="leap">闰{0}</monthPattern> 864 </monthPatternWidth> 865 </monthPatternContext> 866 <monthPatternContext type="numeric"> 867 <monthPatternWidth type="all"> 868 <monthPattern type="leap">闰{0}</monthPattern> 869 </monthPatternWidth> 870 </monthPatternContext> 871 </monthPatterns> 872 <cyclicNameSets> 873 <cyclicNameSet type="years"> 874 <cyclicNameContext type="format"> 875 <cyclicNameWidth type="abbreviated"> 876 <cyclicName type="1">甲子</cyclicName> 877 <cyclicName type="2">乙丑</cyclicName> 878 ... 879 <cyclicName type="59">壬戌</cyclicName> 880 <cyclicName type="60">癸亥</cyclicName> 881 </cyclicNameWidth> 882 </cyclicNameContext> 883 </cyclicNameSet> 884 <cyclicNameSet type="zodiacs"> 885 <cyclicNameContext type="format"> 886 <cyclicNameWidth type="abbreviated"> 887 <cyclicName type="1">鼠</cyclicName> 888 <cyclicName type="2">牛</cyclicName> 889 ... 890 <cyclicName type="11">狗</cyclicName> 891 <cyclicName type="12">猪</cyclicName> 892 </cyclicNameWidth> 893 </cyclicNameContext> 894 </cyclicNameSet> 895 <cyclicNameSet type="solarTerms"> 896 <cyclicNameContext type="format"> 897 <cyclicNameWidth type="abbreviated"> 898 <cyclicName type="1">立春</cyclicName> 899 <cyclicName type="2">雨水</cyclicName> 900 ... 901 <cyclicName type="23">小寒</cyclicName> 902 <cyclicName type="24">大寒</cyclicName> 903 </cyclicNameWidth> 904 </cyclicNameContext> 905 </cyclicNameSet> 906 </cyclicNameSets> 907</pre> 908 <h3>2.3 <a name="dayPeriods" href="#dayPeriods" id= 909 "dayPeriods">Element dayPeriods</a></h3> 910 <p>The former am/pm elements have been deprecated, and replaced 911 by the more flexible dayPeriods.</p> 912 <p class="dtd"><!ELEMENT dayPeriods ( alias | 913 (dayPeriodContext*) ) ></p> 914 <p class="dtd"><!ELEMENT dayPeriodContext (alias | 915 dayPeriodWidth*) ><br> 916 <!ATTLIST dayPeriodContext type NMTOKEN #REQUIRED ></p> 917 <p class="dtd"><!ELEMENT dayPeriodWidth (alias | dayPeriod*) 918 ><br> 919 <!ATTLIST dayPeriodWidth type NMTOKEN #REQUIRED ></p> 920 <p class="dtd"><!ELEMENT dayPeriod ( #PCDATA ) ><br> 921 <!ATTLIST dayPeriod type NMTOKEN #REQUIRED ></p> 922 <p>These behave like months, days, and so on in terms of having 923 context and width. Each locale has an associated 924 dayPeriodRuleSet in the supplemental data, rules that specify 925 when the day periods start and end for that locale. Each type 926 in the rules needs to have a translation in a dayPeriod (but if 927 translation data is missing for a particular variable dayPeriod 928 in the locale’s language and script, formatting should fall 929 back to using the am/pm values). For more information, see 930 <em><a href="#Day_Period_Rules">Day Period Rules</a></em>.</p> 931 <p>The dayPeriod names should be distinct within each of the 932 context/width combinations, including narrow; as with era 933 names, there is less disambiguating information for them, and 934 they are more likely to be used in a format that requires 935 parsing. In some unambiguous cases, it is acceptable for 936 certain overlapping dayPeriods to be the same, such as the 937 names for "am" and "morning", or the names for "pm" and 938 "afternoon".</p> 939 <p class="example">Example:</p> 940 <pre> 941 <dayPeriods> 942 <dayPeriodContext type="format"> 943 <dayPeriodWidth type="wide"> 944 <dayPeriod type="am">AM</dayPeriod> 945 <dayPeriod type="noon">noon</dayPeriod> 946 <dayPeriod type="pm">PM</dayPeriod> 947 </dayPeriodWidth> 948 </dayPeriodContext> 949 </dayPeriods> 950</pre> 951 <h3>2.4 <a name="dateFormats" href="#dateFormats" id= 952 "dateFormats">Element dateFormats</a></h3> 953 <p class="dtd"><!ELEMENT dateFormats (alias | (default*, 954 dateFormatLength*, special*)) ><br> 955 <!ELEMENT dateFormatLength (alias | (default*, dateFormat*, 956 special*)) ><br> 957 <!ATTLIST dateFormatLength type ( full | long | medium | 958 short ) #REQUIRED ><br> 959 <!ELEMENT dateFormat (alias | (pattern*, displayName*, 960 special*)) ></p> 961 <p>Standard date formats have the following form:</p> 962 <pre> <dateFormats> 963 <dateFormatLength type=”<span style= 964"color: blue">full</span>”> 965 <dateFormat> 966 <pattern><span style= 967"color: blue">EEEE, MMMM d, y</span></pattern> 968 </dateFormat> 969 </dateFormatLength> 970 <dateFormatLength type="<span style= 971"color: blue">medium</span>"> 972 <dateFormat type="<span style= 973"color: blue">DateFormatsKey2</span>"> 974 <pattern><span style= 975"color: blue">MMM d, y</span></pattern> 976 </dateFormat> 977 </dateFormatLength> 978 <dateFormats></pre> 979 <p>The patterns for date formats and time formats are defined 980 in <i><a href="#Date_Format_Patterns">Date Format 981 Patterns</a>.</i> These patterns are intended primarily for 982 display of isolated date and time strings in user-interface 983 elements, rather than for date and time strings in the middle 984 of running text, so capitalization and grammatical form should 985 be chosen appropriately.</p> 986 <p>Standard date and time patterns are each normally provided 987 in four types: full (usually with weekday name), long (with 988 wide month name), medium, and short (usually with numeric 989 month).</p> 990 <h3>2.5 <a name="timeFormats" href="#timeFormats" id= 991 "timeFormats">Element timeFormats</a></h3> 992 <p class="dtd"><!ELEMENT timeFormats (alias | (default*, 993 timeFormatLength*, special*)) ><br> 994 <!ELEMENT timeFormatLength (alias | (default*, timeFormat*, 995 special*)) ><br> 996 <!ATTLIST timeFormatLength type ( full | long | medium | 997 short ) #REQUIRED ><br> 998 <!ELEMENT timeFormat (alias | (pattern*, displayName*, 999 special*)) ></p> 1000 <p>Standard time formats have the following form:</p> 1001 <pre> <timeFormats> 1002 <timeFormatLength type=”<span style= 1003"color: blue">full</span>”> 1004 <timeFormat> 1005 <displayName><span style= 1006"color: blue">DIN 5008 (EN 28601)</span></displayName> 1007 <pattern><span style= 1008"color: blue">h:mm:ss a z</span></pattern> 1009 </timeFormat> 1010 </timeFormatLength> 1011 <timeFormatLength type="<span style= 1012"color: blue">medium</span>"> 1013 <timeFormat> 1014 <pattern><span style= 1015"color: blue">h:mm:ss a</span></pattern> 1016 </timeFormat> 1017 </timeFormatLength> 1018 </timeFormats></pre> 1019 <p>The preference of 12 hour versus 24 hour for the locale can 1020 be derived from the <a href="#Time_Data">Time Data</a>. If the 1021 preferred hour symbol is 'h' or 'K' 1022 then the format is 12 hour; otherwise it is 24 hour. Formats 1023 with 'h' or 'K' must also include a field with one of the day 1024 period pattern characters: 'a', 'b', or 'B'.</p> 1025 <p>To account for customary usage in some countries, APIs 1026 should allow for formatting times that go beyond 23:59:59. For 1027 example, in some countries it would be customary to indicate 1028 that opening hours extending from <em>Friday at 7pm</em> to 1029 <em>Saturday at 2am</em> in a format like the following:</p> 1030 <p style="text-align: center">Friday: 19:00 – 26:00</p> 1031 <p>Time formats use the specific non-location format (z or 1032 zzzz) for the time zone name. This is the format that should be 1033 used when formatting a specific time for presentation. When 1034 formatting a time referring to a recurring time (such as a 1035 meeting in a calendar), applications should substitute the 1036 generic non-location format (v or vvvv) for the time zone in 1037 the time format pattern. See <i><a href= 1038 "#Using_Time_Zone_Names">Using Time Zone Names</a>.</i> for a 1039 complete description of available time zone formats and their 1040 uses.</p> 1041 <h3>2.6 <a name="dateTimeFormats" href="#dateTimeFormats" id= 1042 "dateTimeFormats">Element dateTimeFormats</a></h3> 1043 <p class="dtd"><!ELEMENT dateTimeFormats (alias | (default*, 1044 dateTimeFormatLength*, availableFormats*, appendItems*, 1045 intervalFormats*, special*)) ><br></p> 1046 <p>Date/Time formats have the following form:</p> 1047 <pre> <dateTimeFormats> 1048 <dateTimeFormatLength type=”<span style= 1049"color: blue">long</span>”> 1050 <dateTimeFormat> 1051 <pattern>{1} 'at' {0}</pattern> 1052 </dateTimeFormat> 1053 </dateTimeFormatLength> 1054 <dateTimeFormatLength type=”<span style= 1055"color: blue">medium</span>”> 1056 <dateTimeFormat> 1057 <pattern>{1}, {0}</pattern> 1058 </dateTimeFormat> 1059 </dateTimeFormatLength> 1060 <availableFormats> 1061 <dateFormatItem id="Hm"><span style= 1062"color: blue">HH:mm</span></dateFormatItem> 1063 <dateFormatItem id="Hms"><span style= 1064"color: blue">HH:mm:ss</span></dateFormatItem> 1065 <dateFormatItem id="M"><span style= 1066"color: blue">L</span></dateFormatItem> 1067 <dateFormatItem id="MEd"><span style= 1068"color: blue">E, M/d</span></dateFormatItem> 1069 <dateFormatItem id="MMM"><span style= 1070"color: blue">LLL</span></dateFormatItem> 1071 <dateFormatItem id="MMMEd"><span style= 1072"color: blue">E, MMM d</span></dateFormatItem> 1073 <dateFormatItem id="MMMMEd"><span style= 1074"color: blue">E, MMMM d</span></dateFormatItem> 1075 <dateFormatItem id="MMMMd"><span style= 1076"color: blue">MMMM d</span></dateFormatItem> 1077 <dateFormatItem id="MMMd"><span style= 1078"color: blue">MMM d</span></dateFormatItem> 1079 <dateFormatItem id="Md"><span style= 1080"color: blue">M/d</span></dateFormatItem> 1081 <dateFormatItem id="d"><span style= 1082"color: blue">d</span></dateFormatItem> 1083 <dateFormatItem id="hm"><span style= 1084"color: blue">h:mm a</span></dateFormatItem> 1085 <dateFormatItem id="ms"><span style= 1086"color: blue">mm:ss</span></dateFormatItem> 1087 <dateFormatItem id="y"><span style= 1088"color: blue">yyyy</span></dateFormatItem> 1089 <dateFormatItem id="yM"><span style= 1090"color: blue">M/yyyy</span></dateFormatItem> 1091 <dateFormatItem id="yMEd"><span style= 1092"color: blue">EEE, M/d/yyyy</span></dateFormatItem> 1093 <dateFormatItem id="yMMM"><span style= 1094"color: blue">MMM yyyy</span></dateFormatItem> 1095 <dateFormatItem id="yMMMEd"><span style= 1096"color: blue">EEE, MMM d, yyyy</span></dateFormatItem> 1097 <dateFormatItem id="yMMMM"><span style= 1098"color: blue">MMMM yyyy</span></dateFormatItem> 1099 <dateFormatItem id="yQ"><span style= 1100"color: blue">Q yyyy</span></dateFormatItem> 1101 <dateFormatItem id="yQQQ"><span style= 1102"color: blue">QQQ yyyy</span></dateFormatItem> 1103 . . . 1104 </availableFormats> 1105 <appendItems> 1106 <appendItem request="<span style= 1107"color: blue">G</span>"><span style= 1108"color: blue">{0} {1}</span></appendItem> 1109 <appendItem request="<span style= 1110"color: blue">w</span>"><span style= 1111"color: blue">{0} ({2}: {1})</span></appendItem> 1112 . . . 1113 </appendItems> 1114 </dateTimeFormats></pre> 1115 <pre> </calendar> 1116 1117 <calendar type="<span style="color: blue">buddhist</span>"> 1118 <eras> 1119 <eraAbbr> 1120 <era type="<span style= 1121"color: blue">0</span>"><span style= 1122"color: blue">BE</span></era> 1123 </eraAbbr> 1124 </eras> 1125 </calendar></pre> 1126 <p>These formats allow for date and time formats to be composed 1127 in various ways.</p> 1128 <h4>2.6.1 <a name="dateTimeFormat" href="#dateTimeFormat" id= 1129 "dateTimeFormat">Element dateTimeFormat</a></h4> 1130 <p class="dtd"><!ELEMENT dateTimeFormatLength (alias | 1131 (default*, dateTimeFormat*, special*))><br> 1132 <!ATTLIST dateTimeFormatLength type ( full | long | medium | 1133 short ) #IMPLIED ><br> 1134 <!ELEMENT dateTimeFormat (alias | (pattern*, displayName*, 1135 special*))></p> 1136 <p>The dateTimeFormat element works like the dateFormats and 1137 timeFormats, except that the pattern is of the form "{1} {0}", 1138 where {0} is replaced by the time format, and {1} is replaced 1139 by the date format, with results such as "8/27/06 7:31 AM". 1140 Except for the substitution markers {0} and {1}, text in the 1141 dateTimeFormat is interpreted as part of a date/time pattern, 1142 and is subject to the same rules described in <a href= 1143 "#Date_Format_Patterns">Date Format Patterns</a>. This includes 1144 the need to enclose ASCII letters in single quotes if they are 1145 intended to represent literal text.</p> 1146 <p>When combining a standard date pattern with a standard time 1147 pattern, the type of dateTimeFormat used to combine them is 1148 determined by the type of the date pattern. For example:</p> 1149 <table cellspacing="0" cellpadding="4" border="1"> 1150 <caption> 1151 <a name="Date_Time_Combination_Examples" href= 1152 "#Date_Time_Combination_Examples" id= 1153 "Date_Time_Combination_Examples">Date-Time Combination 1154 Examples</a> 1155 </caption> 1156 <tr> 1157 <th>Date-Time Combination</th> 1158 <th>dateTimeFormat</th> 1159 <th>Results</th> 1160 </tr> 1161 <tr> 1162 <td>full date + short time</td> 1163 <td>full, e.g. "{1} 'at' {0}"</td> 1164 <td>Wednesday, September 18, 2013 at 4:30 PM</td> 1165 </tr> 1166 <tr> 1167 <td>medium date + long time</td> 1168 <td>medium, e.g. "{1}, {0}"</td> 1169 <td>Sep 18, 2013, 4:30:00 PM PDT</td> 1170 </tr> 1171 </table> 1172 <h4>2.6.2 <a name="availableFormats_appendItems" href= 1173 "#availableFormats_appendItems" id= 1174 "availableFormats_appendItems">Elements availableFormats, 1175 appendItems</a></h4> 1176 <p class="dtd"><!ELEMENT availableFormats (alias | 1177 (dateFormatItem*, special*))><br> 1178 <!ELEMENT dateFormatItem ( #PCDATA ) ><br> 1179 <!ATTLIST dateFormatItem id CDATA #REQUIRED ></p> 1180 <p>The availableFormats element and its subelements provide a 1181 more flexible formatting mechanism than the predefined list of 1182 patterns represented by dateFormatLength, timeFormatLength, and 1183 dateTimeFormatLength. Instead, there is an open-ended list of 1184 patterns (represented by dateFormatItem elements as well as the 1185 predefined patterns mentioned above) that can be matched 1186 against a requested set of calendar fields and field lengths. 1187 Software can look through the list and find the pattern that 1188 best matches the original request, based on the desired 1189 calendar fields and lengths. For example, the full month and 1190 year may be needed for a calendar application; the request is 1191 MMMMyyyy, but the best match may be "y MMMM" or even "G yy 1192 MMMM", depending on the locale and calendar.</p> 1193 <p>For some calendars, such as Japanese, a displayed year must 1194 have an associated era, so for these calendars dateFormatItem 1195 patterns with a year field should also include an era field. 1196 When matching availableFormats patterns: If a client requests a 1197 format string containing a year, and all the availableFormats 1198 patterns with a year also contain an era, then include the era 1199 as part of the result.</p> 1200 <p>The id attribute is a so-called "skeleton", containing only 1201 field information, and in a canonical order. Examples are 1202 "yMMMM" for year + full month, or "MMMd" for abbreviated month 1203 + day. In particular:</p> 1204 <ul> 1205 <li>The fields are from the <a href= 1206 "#Date_Field_Symbol_Table">Date Field Symbol Table</a> in 1207 <i><a href="#Date_Format_Patterns">Date Format 1208 Patterns</a></i>.</li> 1209 <li>The canonical order is from top to bottom in that table; 1210 that is, "yM" not "My".</li> 1211 <li>Only one field of each type is allowed; that is, "Hh" is 1212 not valid.</li> 1213 </ul> 1214 <p>In order to support user overrides of default locale 1215 behavior, data should be supplied for both 12-hour-cycle time 1216 formats (using h or K) and 24-hour-cycle time formats (using H 1217 or k), even if one of those styles is not commonly used; the 1218 locale's actual preference for 12-hour or 24-hour time cycle is 1219 determined from the <a 1220 href="#Time_Data">Time Data</a> as described above in 1221 <a href="#timeFormats">timeFormats</a>. Thus skeletons 1222 using h or K should have patterns that only use h or K for 1223 hours, while skeletons using H or k should have patterns that 1224 only use H or k for hours.</p> 1225 <p>The rules governing use of day period pattern characters in 1226 patterns and skeletons are as follows:</p> 1227 <ul> 1228 <li>Patterns and skeletons for 24-hour-cycle time formats 1229 (using H or k) currently <em>should not</em> include fields 1230 with day period characters (a, b, or B); these pattern 1231 characters should be ignored if they appear in skeletons. 1232 However, in the future, CLDR may allow use of B (but not a or 1233 b) in 24-hour-cycle time formats.</li> 1234 <li>Patterns for 12-hour-cycle time formats (using h or K) 1235 <em>must</em> include a day period field using one of a, b, 1236 or B.</li> 1237 <li>Skeletons for 12-hour-cycle time formats (using h or K) 1238 <em>may</em> include a day period field using one of a, b, or 1239 B. If they do not, the skeleton will be treated as implicitly 1240 containing a.</li> 1241 </ul> 1242 <p>Locales should generally provide availableFormats data for a 1243 fairly complete set of time skeletons without B, typically the 1244 following:</p><code>H, h, Hm, hm, Hms, hms, Hmv, hmv, Hmsv, 1245 hmsv</code> 1246 <p>Locales that use 12-hour-cycle time formats with B may 1247 provide availableFormats data for a smaller set of time 1248 skeletons with B, for example:</p><code>Bh, Bhm, Bhms</code> 1249 <p>When matching a requested skeleton containing b or B to the 1250 skeletons actually available in the data, if there is no 1251 skeleton matching the specified day period field, then find a 1252 match in which the b or B matches an explicit or implicit 'a' 1253 in the skeleton, but replace the 'a' in the corresponding 1254 pattern with the requested day period b or B. The following 1255 table illustrates how requested skeletons map to patterns with 1256 different sets of availableFormats data:</p> 1257 <table cellspacing="0" cellpadding="4" border="1"> 1258 <caption> 1259 <a name="Mapping_Requested_Time_Skeletons_To_Patterns" 1260 href="#Mapping_Requested_Time_Skeletons_To_Patterns" id= 1261 "Mapping_Requested_Time_Skeletons_To_Patterns">Mapping 1262 Requested Time Skeletons To Patterns</a> 1263 </caption> 1264 <tr> 1265 <th></th> 1266 <th colspan="2">results for different availableFormats data 1267 sets</th> 1268 </tr> 1269 <tr> 1270 <th>requested skeleton</th> 1271 <th>set 1:<br> 1272 ...id="H">H</date...<br> 1273 ...id="h">h a</date...</th> 1274 <th>set 2:<br> 1275 ...id="H">H</date...<br> 1276 ...id="h">h a</date...<br> 1277 ...id="Bh">B h</date...</th> 1278 </tr> 1279 <tr> 1280 <td>"h" (or "ah")</td> 1281 <td>"h a"</td> 1282 <td>"h a"</td> 1283 </tr> 1284 <tr> 1285 <td>"bh"</td> 1286 <td>"h b"</td> 1287 <td>"h b"</td> 1288 </tr> 1289 <tr> 1290 <td>"Bh"</td> 1291 <td>"h B"</td> 1292 <td>"B h"</td> 1293 </tr> 1294 <tr> 1295 <td>"H" (or "aH", "bH", "BH")</td> 1296 <td>"H"</td> 1297 <td>"H"</td> 1298 </tr> 1299 </table><br> 1300 <p>The hour input skeleton symbols 'j', 'J', and 'C' can be 1301 used to select the best hour format (h, H, …) before 1302 processing, and the appropriate dayperiod format (a, b, B) 1303 after a successful match that contains an 'a' symbol.</p> 1304 <p>The dateFormatItems inherit from their parent locale, so the 1305 inherited items need to be considered when processing.</p> 1306 <h5><a name="Matching_Skeletons" href="#Matching_Skeletons" id= 1307 "Matching_Skeletons">2.6.2.1 Matching Skeletons</a></h5> 1308 <p>It is not necessary to supply dateFormatItems with skeletons 1309 for every field length; fields in the skeleton and pattern are 1310 expected to be expanded in parallel to handle a request.</p> 1311 <p>Typically a “best match” is found using a closest distance 1312 match, such as:</p> 1313 <ol> 1314 <li>Symbols requesting a best choice for the locale are 1315 replaced. 1316 <ul> 1317 <li>j → one of {H, k, h, K}; C → one of {a, b, B}</li> 1318 </ul> 1319 </li> 1320 <li>For fields with symbols representing the same type (year, 1321 month, day, etc): 1322 <ol> 1323 <li>Most symbols have a small distance from each other. 1324 <ul> 1325 <li>M ≅ L; E ≅ c; a ≅ b ≅ B; H ≅ k ≅ h ≅ K; ...</li> 1326 </ul> 1327 </li> 1328 <li>Width differences among fields, other than those 1329 marking text vs numeric, are given small distance from 1330 each other. 1331 <ul> 1332 <li>MMM ≅ MMMM</li> 1333 <li>MM ≅ M</li> 1334 </ul> 1335 </li> 1336 <li>Numeric and text fields are given a larger distance 1337 from each other. 1338 <ul> 1339 <li>MMM ≈ MM</li> 1340 </ul> 1341 </li> 1342 <li>Symbols representing substantial differences (week of 1343 year vs week of month) are given much larger a distances 1344 from each other. 1345 <ul> 1346 <li>d ≋ D; ...</li> 1347 </ul> 1348 </li> 1349 </ol> 1350 </li> 1351 <li>A requested skeleton that includes both seconds and 1352 fractional seconds (e.g. “mmssSSS”) is allowed to match a 1353 dateFormatItem skeleton that includes seconds but not 1354 fractional seconds (e.g. “ms”). In this case the requested 1355 sequence of ‘S’ characters (or its length) should be retained 1356 separately and used when adjusting the pattern, as described 1357 below.</li> 1358 <li>Otherwise, missing or extra fields cause a match to fail. 1359 (But see <strong><a href="#Missing_Skeleton_Fields">Missing 1360 Skeleton Fields</a></strong> below).</li> 1361 </ol> 1362 <p>Once a skeleton match is found, the corresponding pattern is 1363 used, but with adjustments. Consider the following 1364 dateFormatItem:</p> 1365 <pre> <dateFormatItem id="yMMMd"><span style= 1366 "color: blue">d MMM y</span></dateFormatItem> 1367</pre> 1368 <p>If this is the best match for yMMMMd, pattern is 1369 automatically expanded to produce the pattern 1370 "d MMMM y" in response to the request. Of course, if 1371 the desired behavior is that a request for yMMMMd should 1372 produce something <i>other</i> than "d MMMM y", a 1373 separate dateFormatItem must be present, for example:</p> 1374 <pre> <dateFormatItem id="yMMMMd"><span style= 1375 "color: blue">d 'de' MMMM 'de' y</span></dateFormatItem></pre> 1376 <p>However, such automatic expansions should never convert a 1377 numeric element in the pattern to an alphabetic element. 1378 Consider the following dateFormatItem:</p> 1379 <pre> 1380 <dateFormatItem id="yMMM">y年M月</dateFormatItem></pre> 1381 <p>If this is the best match for a requested skeleton yMMMM, 1382 automatic expansion should not produce a corresponding pattern 1383 “y年MMMM月”; rather, since “y年M月” specifies a numeric month M, 1384 automatic expansion should not modify the pattern, and should 1385 produce “y年M月” as the match for requested skeleton yMMMM.</p> 1386 <p>If the requested skeleton included both seconds and 1387 fractional seconds and the dateFormatItem skeleton included 1388 seconds but not fractional seconds, then the seconds field of 1389 the corresponding pattern should be adjusted by appending the 1390 locale’s decimal separator, followed by the sequence of ‘S’ 1391 characters from the requested skeleton.</p> 1392 <h5><a name="Missing_Skeleton_Fields" href= 1393 "#Missing_Skeleton_Fields" id="Missing_Skeleton_Fields">2.6.2.2 1394 Missing Skeleton Fields</a></h5> 1395 <p>If a client-requested set of fields includes both date and 1396 time fields, and if the availableFormats data does not include 1397 a dateFormatItem whose skeleton matches the same set of fields, 1398 then the request should be handled as follows:</p> 1399 <ol> 1400 <li>Divide the request into a date fields part and a time 1401 fields part.</li> 1402 <li>For each part, find the matching dateFormatItem, and 1403 expand the pattern as above.</li> 1404 <li>Combine the patterns for the two dateFormatItems using 1405 the appropriate dateTimeFormat pattern, determined as follows 1406 from the requested date fields: 1407 <ul> 1408 <li>If the requested date fields include wide month 1409 (MMMM, LLLL) and weekday name of any length (e.g. E, 1410 EEEE, c, cccc), use 1411 <dateTimeFormatLength type="full"></li> 1412 <li>Otherwise, if the requested date fields include wide 1413 month, use 1414 <dateTimeFormatLength type="long"></li> 1415 <li>Otherwise, if the requested date fields include 1416 abbreviated month (MMM, LLL), use 1417 <dateTimeFormatLength type="medium"></li> 1418 <li>Otherwise use <dateTimeFormatLength 1419 type="short"></li> 1420 </ul> 1421 </li> 1422 </ol> 1423 <p class="dtd"><!ELEMENT appendItems (alias | (appendItem*, 1424 special*))><br> 1425 <!ELEMENT appendItem ( #PCDATA ) ><br> 1426 <!ATTLIST appendItem request CDATA ></p> 1427 <p>In case the best match does not include all the requested 1428 calendar fields, the appendItems element describes how to 1429 append needed fields to one of the existing formats. Each 1430 appendItem element covers a single calendar field. In the 1431 pattern, {0} represents the format string, {1} the data content 1432 of the field, and {2} the display name of the field (see 1433 <a href="#Calendar_Fields">Calendar Fields</a>).</p> 1434 <h4>2.6.3 <a name="intervalFormats" href="#intervalFormats" id= 1435 "intervalFormats">Element intervalFormats</a></h4> 1436 <p class="dtd"><!ELEMENT intervalFormats (alias | 1437 (intervalFormatFallback*, intervalFormatItem*, special*)) 1438 ></p> 1439 <p class="dtd"><!ELEMENT intervalFormatFallback ( #PCDATA ) 1440 ></p> 1441 <p class="dtd"><!ELEMENT intervalFormatItem (alias | 1442 (greatestDifference*, special*)) ><br> 1443 <!ATTLIST intervalFormatItem id NMTOKEN #REQUIRED ></p> 1444 <p class="dtd"><!ELEMENT greatestDifference ( #PCDATA ) 1445 ><br> 1446 <!ATTLIST greatestDifference id NMTOKEN #REQUIRED ></p> 1447 <p>Interval formats allow for software to format intervals like 1448 "Jan 10-12, 2008" as a shorter and more natural format than 1449 "Jan 10, 2008 - Jan 12, 2008". They are designed to take a 1450 "skeleton" pattern (like the one used in availableFormats) plus 1451 start and end datetime, and use that information to produce a 1452 localized format.</p> 1453 <p>The data supplied in CLDR requires the software to determine 1454 the calendar field with the greatest difference before using 1455 the format pattern. For example, the greatest difference in 1456 "Jan 10-12, 2008" is the day field, while the greatest 1457 difference in "Jan 10 - Feb 12, 2008" is the month field. This 1458 is used to pick the exact pattern. The pattern is then designed 1459 to be broken up into two pieces by determining the first 1460 repeating field. For example, "MMM d-d, y" would be broken up 1461 into "MMM d-" and "d, y". The two parts are formatted with the 1462 first and second datetime, as described in more detail 1463 below.</p> 1464 <p>In case there is no matching pattern, the 1465 intervalFormatFallback defines the fallback pattern. The 1466 fallback pattern is of the form "{0} - {1}" or "{1} - {0}", 1467 where {0} is replaced by the start datetime, and {1} is 1468 replaced by the end datetime. The fallback pattern determines 1469 the default order of the interval pattern. "{0} - {1}" means 1470 the first part of the interval patterns in current local are 1471 formatted with the start datetime, while "{1} - {0}" means the 1472 first part of the interval patterns in current locale are 1473 formatted with the end datetime.</p> 1474 <p>The id attribute of intervalFormatItem is the "skeleton" 1475 pattern (like the one used in availableFormats) on which the 1476 format pattern is based. The id attribute of greatestDifference 1477 is the calendar field letter, for example 'M', which is the 1478 greatest difference between start and end datetime.</p> 1479 <p>The greatest difference defines a specific interval pattern 1480 of start and end datetime on a "skeleton" and a 1481 greatestDifference. As stated above, the interval pattern is 1482 designed to be broken up into two pieces. Each piece is similar 1483 to the pattern defined in date format. Also, each interval 1484 pattern could override the default order defined in fallback 1485 pattern. If an interval pattern starts with "latestFirst:", the 1486 first part of this particular interval pattern is formatted 1487 with the end datetime. If an interval pattern starts with 1488 "earliestFirst:", the first part of this particular interval 1489 pattern is formatted with the start datetime. Otherwise, the 1490 order is the same as the order defined in 1491 intervalFormatFallback.</p> 1492 <p>For example, the English rules that produce "Jan 10–12, 1493 2008", "Jan 10 – Feb 12, 2008", and "Jan 10, 2008 – Feb. 12, 1494 2009" are as follows:</p> 1495 <p class="example"><intervalFormatItem id="yMMMd"><br> 1496 <greatestDifference id="M">MMM d – MMM d, 1497 yyyy</greatestDifference><br> 1498 <greatestDifference id="d">MMM d–d, 1499 yyyy</greatestDifference><br> 1500 <greatestDifference id="y">MMM d, yyyy – MMM d, 1501 yyyy</greatestDifference><br> 1502 </intervalFormatItem></p> 1503 <p>To format a start and end datetime, given a particular 1504 "skeleton":</p> 1505 <ol> 1506 <li>Look for the intervalFormatItem element that matches the 1507 "skeleton", starting in the current locale and then following 1508 the locale fallback chain up to, but not including root 1509 (better results are obtained by following steps 2-6 below 1510 with locale- or language- specific data than by using 1511 matching intervalFormats from root).</li> 1512 <li>If no match was found from the previous step, check what 1513 the closest match is in the fallback locale chain, as in 1514 availableFormats. That is, this allows for adjusting the 1515 string value field's width, including adjusting between "MMM" 1516 and "MMMM", and using different variants of the same field, 1517 such as 'v' and 'z'.</li> 1518 <li>If no match was found from the previous steps and the 1519 skeleton combines date fields such as y,M,d with time fields 1520 such as H,h,m,s, then an intervalFormatItem can be 1521 synthesized as follows: 1522 <ol> 1523 <li>For greatestDifference values corresponding to the 1524 date fields in the skeleton, use the mechanisms described 1525 under <a href= 1526 "#availableFormats_appendItems">availableFormats</a> to 1527 generate the complete date-time pattern corresponding to 1528 the skeleton, and then combine two such patterns using 1529 the intervalFormatFallback pattern (the result will be 1530 the same for each greatestDifference of a day or longer). 1531 For example:<br> 1532 MMMdHm/d → "MMM d 'at' H:mm – MMM d 'at' H:mm" → "Jan 3 1533 at 9:00 – Jan 6 at 11:00"</li> 1534 <li>For greatestDifference values corresponding to the 1535 time fields in the skeleton, separate the skeleton into a 1536 date fields part and a time fields part. Use the 1537 mechanisms described under availableFormats to generate a 1538 date pattern corresponding to the date fields part. Use 1539 the time fields part to look up an intervalFormatItem. 1540 For each greatestDifferent in the intervalFormatItem, 1541 generate a pattern by using the <a href= 1542 "#dateTimeFormat">dateTimeFormat</a> to combine the date 1543 pattern with the intervalFormatItem’s greatestDifference 1544 element value. For example:<br> 1545 MMMdHm/H → "MMM d 'at' H:mm – H:mm" → "Jan 3 at 9:00 – 1546 11:00"</li> 1547 </ol> 1548 </li> 1549 <li>If a match is found from previous steps, compute the 1550 calendar field with the greatest difference between start and 1551 end datetime. If there is no difference among any of the 1552 fields in the pattern, format as a single date using 1553 availableFormats, and return.</li> 1554 <li>Otherwise, look for greatestDifference element that 1555 matches this particular greatest difference.</li> 1556 <li>If there is a match, use the pieces of the corresponding 1557 pattern to format the start and end datetime, as above.</li> 1558 <li>Otherwise, format the start and end datetime using the 1559 fallback pattern.</li> 1560 </ol> 1561 <h2>3 <a name="Calendar_Fields" href="#Calendar_Fields" id= 1562 "Calendar_Fields">Calendar Fields</a></h2> 1563 <p class="dtd"><!ELEMENT fields ( alias | (field*, 1564 special*)) ><br> 1565 <!ELEMENT field ( alias | (displayName*, relative*, 1566 relativeTime*, relativePeriod*, special*)) ><br> 1567 <!ATTLIST field type ( era | era-short | era-narrow | year | 1568 year-short | year-narrow | quarter | quarter-short | 1569 quarter-narrow | month | month-short | month-narrow | week | 1570 week-short | week-narrow | weekOfMonth | weekOfMonth-short | 1571 weekOfMonth-narrow | day | day-short | day-narrow | dayOfYear | 1572 dayOfYear-short | dayOfYear-narrow | weekday | weekday-short | 1573 weekday-narrow | weekdayOfMonth | weekdayOfMonth-short | 1574 weekdayOfMonth-narrow | sun | sun-short | sun-narrow | mon | 1575 mon-short | mon-narrow | tue | tue-short | tue-narrow | wed | 1576 wed-short | wed-narrow | thu | thu-short | thu-narrow | fri | 1577 fri-short | fri-narrow | sat | sat-short | sat-narrow | 1578 dayperiod | dayperiod-short | dayperiod-narrow | hour | 1579 hour-short | hour-narrow | minute | minute-short | 1580 minute-narrow | second | second-short | second-narrow | zone | 1581 zone-short | zone-narrow ) #IMPLIED ></p> 1582 <p class="dtd"><!ELEMENT relative (#PCDATA) ><br> 1583 <!ATTLIST relative type NMTOKEN #IMPLIED ></p> 1584 <p class="dtd"><!ELEMENT relativeTime ( alias | 1585 (relativeTimePattern*, special*)) ><br> 1586 <!ATTLIST relativeTime type NMTOKEN #REQUIRED ></p> 1587 <p class="dtd"><!ELEMENT relativeTimePattern ( #PCDATA ) 1588 ><br> 1589 <!ATTLIST relativeTimePattern count ( zero | one | two | few 1590 | many | other ) #REQUIRED ></p> 1591 <p class="dtd"><!ELEMENT relativePeriod (#PCDATA) ></p> 1592 <p>Translations may be supplied for names of calendar fields 1593 (elements of a calendar, such as Day, Month, Year, Hour, and so 1594 on), and for relative values for those fields (for example, the 1595 day with relative value -1 is "Yesterday"). There are four 1596 types of translations; some are only relevant or useful for 1597 certain types of fields:</p> 1598 <ul> 1599 <li><displayName> General display name for the field 1600 type. This should be relevant for all elements, including 1601 those like era and zone that might not have useful forms for 1602 the other name types. These are typically presented in 1603 titlecase (eg “Day”) since they are intended as labels in a 1604 UI.</li> 1605 <li><relative> Display names for the current instance 1606 of the field, and one or two past and future instances. In 1607 English, data is provided for year, quarter, month, week, 1608 day, specific days of the week (sun, mon, tue, …), and—with 1609 offset 0 only—for hour, minute, and second.</li> 1610 <li><relativeTime> Display names for an instance of the 1611 field that is a counted number of units in the past or the 1612 future relative to the current instance; this needs plural 1613 forms. In English, data is provided for year, quarter, month, 1614 week, day, specific days of the week, ,hour, minute, and 1615 second.</li> 1616 <li><relativePeriod> Pattern for designating an 1617 instance of the specified field in relation to some other 1618 date reference. This is currently only used for weeks, and 1619 provides a pattern such as “the week of {0}” which can be 1620 used to generate designations such as “the week of April 11, 1621 2016” or “the week of April 11–15”.</li> 1622 </ul> 1623 <p>Where there is not a convenient, customary word or phrase in 1624 a particular language for a particular type of relative value, 1625 it should be omitted.</p> 1626 <p>Examples, first for English:</p> 1627 <pre> <fields> 1628 … 1629 <field type="day"> 1630 <displayName>Day</displayName> 1631 <relative type="-1">yesterday</relative> 1632 <relative type="0">today</relative> 1633 <relative type="1">tomorrow</relative> 1634 <relativeTime type="future"> 1635 <relativeTimePattern count="one">in {0} day</relativeTimePattern> 1636 <relativeTimePattern count="other">in {0} days</relativeTimePattern> 1637 </relativeTime> 1638 <relativeTime type="past"> 1639 <relativeTimePattern count="one">{0} day ago</relativeTimePattern> 1640 <relativeTimePattern count="other">{0} days ago</relativeTimePattern> 1641 </relativeTime> 1642 </field> 1643 <field type="weekday"> 1644 <displayName>Day of the Week</displayName> 1645 </field> 1646 <field type="sun"> 1647 <relative type="-1">last Sunday</relative> 1648 <relative type="0">this Sunday</relative> 1649 <relative type="1">next Sunday</relative> 1650 <relativeTime type="future"> 1651 <relativeTimePattern count="one">in {0} Sunday</relativeTimePattern> 1652 <relativeTimePattern count="other">in {0} Sundays</relativeTimePattern> 1653 </relativeTime> 1654 <relativeTime type="past"> 1655 <relativeTimePattern count="one">{0} Sunday ago</relativeTimePattern> 1656 <relativeTimePattern count="other">{0} Sundays ago</relativeTimePattern> 1657 </relativeTime> 1658 </field> 1659 … 1660 <field type="hour"> 1661 <displayName>Hour</displayName> 1662 <relative type="0">now</relative> 1663 <relativeTime type="future"> 1664 <relativeTimePattern count="one">in {0} hour</relativeTimePattern> 1665 <relativeTimePattern count="other">in {0} hours</relativeTimePattern> 1666 </relativeTime> 1667 <relativeTime type="past"> 1668 <relativeTimePattern count="one">{0} hour ago</relativeTimePattern> 1669 <relativeTimePattern count="other">{0} hours ago</relativeTimePattern> 1670 </relativeTime> 1671 </field> 1672 … 1673 </fields> 1674</pre> 1675 <p>Second, for German; includes relative type="-2"/"2", present 1676 in the English example:</p> 1677 <pre> <fields> 1678 … 1679 <field type="day"> 1680 <displayName>Tag</displayName> 1681 <relative type="-2">Vorgestern</relative> 1682 <relative type="-1">Gestern</relative> 1683 <relative type="0">Heute</relative> 1684 <relative type="1">Morgen</relative> 1685 <relative type="2">Übermorgen</relative> 1686 <relativeTime type="future"> 1687 <relativeTimePattern count="one">In {0} Tag</relativeTimePattern> 1688 <relativeTimePattern count="other">In {0} Tagen</relativeTimePattern> 1689 </relativeTime> 1690 <relativeTime type="past"> 1691 <relativeTimePattern count="one">Vor {0} Tag</relativeTimePattern> 1692 <relativeTimePattern count="other">Vor {0} Tagen</relativeTimePattern> 1693 </relativeTime> 1694 </field> 1695 … 1696 </fields> 1697</pre> 1698 <p>A special name for “now” is indicated using <relative 1699 type="0"> for the "second" field. For example, in 1700 English:</p> 1701 <pre> <field type="second"> 1702 <displayName>Second</displayName> 1703 <relative type="0">now</relative> 1704 … 1705 </field></pre> 1706 <p>Different widths can be supplied for certain fields, such 1707 as:</p> 1708 <pre> 1709 <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> 1710 <p>As in other cases, <strong>narrow</strong> may be ambiguous 1711 out of context.</p> 1712 <h2>4 <a name="Supplemental_Calendar_Data" href= 1713 "#Supplemental_Calendar_Data" id= 1714 "Supplemental_Calendar_Data">Supplemental Calendar 1715 Data</a></h2> 1716 <h3>4.1 <a name="Calendar_Data" href="#Calendar_Data" id= 1717 "Calendar_Data">Calendar Data</a></h3> 1718 <p class="dtd"><!ELEMENT calendarData ( calendar* )><br> 1719 <!ELEMENT calendar ( calendarSystem?, eras? )><br> 1720 <!ATTLIST calendar type NMTOKENS #REQUIRED><br> 1721 <!ATTLIST calendar territories NMTOKENS #IMPLIED > 1722 <!-- deprecated, replaced by calendarPreferenceData 1723 --></p> 1724 <p class="dtd"><!ELEMENT calendarSystem EMPTY><br> 1725 <!ATTLIST calendarSystem type (solar | lunar | lunisolar | 1726 other) #REQUIRED></p> 1727 <p class="dtd"><!ELEMENT eras ( era* )></p> 1728 <p class="dtd"><!ELEMENT era EMPTY><br> 1729 <!ATTLIST era type NMTOKENS #REQUIRED><br> 1730 <!ATTLIST era start CDATA #IMPLIED><br> 1731 <!ATTLIST era end CDATA #IMPLIED></p> 1732 <p>The <calendarData> element now provides only 1733 locale-independent data about calendar behaviors via its 1734 <calendar> subelements, which for each calendar can 1735 specify the astronomical basis of the calendar (solar, lunar, 1736 etc.) and the date ranges for its eras.</p> 1737 <p>Era start or end dates are specified in terms of the 1738 equivalent proleptic Gregorian date (in "y-M-d" format). Eras 1739 may be open-ended, with unspecified start or end dates. For 1740 example, here are the eras for the Gregorian calendar:</p> 1741 <pre> <era type="0" end="0" /> 1742 <era type="1" start="1" /> 1743</pre> 1744 <p>For a sequence of eras with specified start dates, the end 1745 of each era need not be explicitly specified (it is assumed to 1746 match the start of the subsequent era). For example, here are 1747 the first few eras for the Japanese calendar:</p> 1748 <pre> <era type="0" start="645-6-19"/> 1749 <era type="1" start="650-2-15"/> 1750 <era type="2" start="672-1-1"/> 1751 … 1752</pre> 1753 <p><b>Note:</b> The territories attribute in the calendar 1754 element is deprecated. It was formerly used to indicate 1755 calendar preference by territory, but this is now given by the 1756 <i><a href="#Calendar_Preference_Data">Calendar Preference 1757 Data</a></i> below.</p> 1758 <h3>4.2 <a name="Calendar_Preference_Data" href= 1759 "#Calendar_Preference_Data" id= 1760 "Calendar_Preference_Data">Calendar Preference Data</a></h3> 1761 <p class="dtd"><!ELEMENT calendarPreferenceData ( 1762 calendarPreference* ) ><br> 1763 <!ELEMENT calendarPreference EMPTY ><br> 1764 <!ATTLIST calendarPreference territories NMTOKENS #REQUIRED 1765 ><br> 1766 <!ATTLIST calendarPreference ordering NMTOKENS #REQUIRED 1767 ></p> 1768 <p>The calendarPreference element provides a list of commonly 1769 used calendar types in a territory. The ordering attribute 1770 indicates the list of calendar types in preferred order. The 1771 first calendar type in the list is the default calendar type 1772 for the territory. For example:</p> 1773 <pre> 1774 <calendarPreference territories="001" ordering="gregorian"/> 1775 <calendarPreference territories="JP" ordering="gregorian japanese"/> 1776 <calendarPreference territories="TH" ordering="buddhist gregorian"/> 1777</pre> 1778 <p>The calendarPreference elements above indicate:</p> 1779 <ul> 1780 <li>The default (for territory "001") is that only the 1781 Gregorian calendar is commonly used.</li> 1782 <li>For Japan, the Gregorian and Japanese calendars are both 1783 used, with Gregorian preferred (the default).</li> 1784 <li>For Thailand, the Buddhist and Gregorian calendars are 1785 both used, and Buddhist is preferred (the default).</li> 1786 </ul> 1787 <p>The calendars in common use for a locale should typically be 1788 shown in UIs that provide a choice of calendars. (An 'Other...' 1789 button could give access to the other available calendars.)</p> 1790 <h3>4.3 <a name="Week_Data" href="#Week_Data" id= 1791 "Week_Data">Week Data</a></h3> 1792 <p class="dtd"><!ELEMENT weekData ( minDays*, firstDay*, 1793 weekendStart*, weekendEnd*, weekOfPreference* )></p> 1794 <p class="dtd"><!ELEMENT minDays EMPTY><br> 1795 <!ATTLIST minDays count (1 | 2 | 3 | 4 | 5 | 6 | 7) 1796 #REQUIRED><br> 1797 <!ATTLIST minDays territories NMTOKENS #REQUIRED></p> 1798 <p class="dtd"><!ELEMENT firstDay EMPTY ><br> 1799 <!ATTLIST firstDay day (sun | mon | tue | wed | thu | fri | 1800 sat) #REQUIRED><br> 1801 <!ATTLIST firstDay territories NMTOKENS #REQUIRED></p> 1802 <p class="dtd"><!ELEMENT weekendStart EMPTY><br> 1803 <!ATTLIST weekendStart day (sun | mon | tue | wed | thu | 1804 fri | sat) #REQUIRED><br> 1805 <!ATTLIST weekendStart territories NMTOKENS 1806 #REQUIRED></p> 1807 <p class="dtd"><!ELEMENT weekendEnd EMPTY><br> 1808 <!ATTLIST weekendEnd day (sun | mon | tue | wed | thu | fri 1809 | sat) #REQUIRED><br> 1810 <!ATTLIST weekendEnd territories NMTOKENS #REQUIRED></p> 1811 <p class="dtd"><!ELEMENT weekOfPreference EMPTY><br> 1812 <!ATTLIST weekOfPreference locales NMTOKENS 1813 #REQUIRED><br> 1814 <!ATTLIST weekOfPreference ordering NMTOKENS 1815 #REQUIRED></p> 1816 <p>These values provide territory-specific information needed 1817 for week-of-year and week-of-month calculations, as well as 1818 information on conventions for first day of the week, for 1819 weekends, and for week designations. For most elements, the 1820 default is provided by the element with territories="001"; for 1821 weekOfPreference elements the default is provided by the 1822 element with locales="und".</p> 1823 <pre><weekData> 1824 <minDays count="1" territories="001"/> 1825 <minDays count="4" territories="AD AN AT AX BE BG CH CZ DE DK EE ES FI FJ FO FR GB …"/> 1826 <firstDay day="mon" territories="001"/> 1827 <firstDay day="fri" territories="BD MV"/> 1828 <firstDay day="sat" territories="AE AF BH DJ DZ EG IQ IR JO …"/> 1829 … 1830 <weekendStart day="sat" territories="001"/> 1831 <weekendStart day="sun" territories="IN"/> 1832 <weekendStart day="thu" territories="AF DZ IR OM SA YE"/> 1833 <weekendStart day="fri" territories="AE BH EG IL IQ JO KW …"/> 1834 … 1835 <weekOfPreference ordering="weekOfYear" locales="und"/> 1836 <weekOfPreference ordering="weekOfYear weekOfMonth" locales="am az bs cs cy da el et hi ky lt mk sk ta th"/> 1837 <weekOfPreference ordering="weekOfYear weekOfMonth weekOfInterval" locales="is mn no sv vi"/> 1838 <weekOfPreference ordering="weekOfYear weekOfDate weekOfMonth" locales="fi zh-TW"/> 1839 … 1840</pre> 1841 <p>In order for a week to count as the first week of a new year 1842 for week-of-year calculations, it must include at least the 1843 number of days in the new year specified by the minDays value; 1844 otherwise the week will count as the last week of the previous 1845 year (and for week-of-month calculations, minDays also 1846 specifies the minimum number of days in the new month for a 1847 week to count as part of that month).</p> 1848 <p>The day indicated by firstDay is the one that should be 1849 shown as the first day of the week in a calendar view. This is 1850 not necessarily the same as the first day after the weekend (or 1851 the first work day of the week), which should be determined 1852 from the weekend information. Currently, day-of-week numbering 1853 is based on firstDay (that is, day 1 is the day specified by 1854 firstDay), but in the future we may add a way to specify this 1855 separately.</p> 1856 <p>What is meant by the weekend varies from country to country. 1857 It is typically when most non-retail businesses are closed. The 1858 time should not be specified unless it is a well-recognized 1859 part of the day. The weekendStart day defaults to "sat", and 1860 weekendEnd day defaults to "sun". For more information, see 1861 <i><a href="tr35.html#Date_Ranges">Dates and Date 1862 Ranges</a></i>.</p> 1863 <p>Each weekOfPreference element provides, for its specified 1864 locales, an ordered list of the preferred types of week 1865 designations for that set of locales. There are four types of 1866 week designations, each of which makes use of date patterns 1867 available in the locale, as follows:</p> 1868 <table cellspacing="0" cellpadding="4" border="1"> 1869 <caption> 1870 <a name="Week_Designation_Types" href= 1871 "#Week_Designation_Types" id="Week_Designation_Types">Week 1872 Designation Types</a> 1873 </caption> 1874 <tr> 1875 <th width="10%">Type</th> 1876 <th width="20%">Examples</th> 1877 <th width="30%">Date Pattern</th> 1878 <th width="40%">Comments</th> 1879 </tr> 1880 <tr> 1881 <td width="10">weekOfYear</td> 1882 <td width="20%">week 15 of 2016</td> 1883 <td width="30%"><dateFormatItem id='yw' 1884 count='one'>'week' w 'of' <span style= 1885 "text-align: center">Y<…</span></td> 1886 <td width="40%" rowspan="2">The <em>week of</em> 1887 construction takes a <strong>count</strong> attribute, just 1888 in case the pattern changes depending on the numeric value. 1889 (In the future, we're likely to add an ordinal value, for 1890 constructions like “3rd week of March”.)<br> 1891 In languages where the month name needs grammatical changes 1892 (aside from just the simple addition of a prefix or 1893 suffix), localizers will typically use a work-around 1894 construction.</td> 1895 </tr> 1896 <tr> 1897 <td width="10%">weekOfMonth</td> 1898 <td width="20%">week 2 of April<br> 1899 2nd week of April</td> 1900 <td width="30%"><dateFormatItem id='MMMMW'' 1901 count='one'>'week' W 'of' MMM<…</td> 1902 </tr> 1903 <tr> 1904 <td width="10%">weekOfDate</td> 1905 <td width="20%">the week of April 11, 2016</td> 1906 <td width="30%" rowspan="2"><field 1907 type="week"><relativePeriod>the week of 1908 {0}<…</td> 1909 <td width="40%" rowspan="2">The date pattern that replaces 1910 {0} is determined separately and may use the first day or 1911 workday of the week, the range of the full week or work 1912 week, etc.</td> 1913 </tr> 1914 <tr> 1915 <td width="10%">weekOfInterval</td> 1916 <td width="20%">the week of April 11–15</td> 1917 </tr> 1918 </table> 1919 <h3>4.4 <a name="Time_Data" href="#Time_Data" id= 1920 "Time_Data">Time Data</a></h3> 1921 <p class="dtd"><!ELEMENT timeData ( hours* ) ><br> 1922 <!ELEMENT hours EMPTY ><br> 1923 <!ATTLIST hours preferred NMTOKEN #REQUIRED ><br> 1924 <!ATTLIST hours allowed NMTOKENS #REQUIRED ><br> 1925 <!ATTLIST hours regions NMTOKENS #REQUIRED ></p> 1926 <p>This element is for data that indicates, for various 1927 regions, the preferred time cycle in the region, as well as all 1928 time cycles that are considered acceptable in the region. The 1929 defaults are those specified for region 001.</p> 1930 <p>There is a single <code>preferred</code> value, and multiple 1931 <code>allowed</code> values. The meanings of the values H, h, 1932 K, k, b and B are defined in <a href= 1933 "#Date_Field_Symbol_Table">Date Field Symbol Table</a>. The 1934 <code>allowed</code> values are in preference order, and are 1935 used with the 'C' hour skeleton pattern symbol.</p> 1936 <p>For example, in the following, RU (Russia) is marked as 1937 using only 24 hour time, and in particular the 24 hour time 1938 that goes from 0..23 (H), rather than from 1..24 (k).</p> 1939 <pre><timeData> 1940 <hours preferred="H" allowed="H h" regions="001 …"/> 1941 <hours preferred="H" allowed="H K h" regions="JP"/> 1942 <hours preferred="H" allowed="H" regions="IL RU"/> 1943 <hours preferred="h" allowed="H h" regions="AE AG AL … US … ZW"/> 1944 …</pre> 1945 <p>The B and b date symbols provide for formats like “3:00 at 1946 night”. When the ‘C’ option is used, the values in 1947 <code>allowed</code> are traversed from first to last, picking 1948 the first available format. For example, in the following a 1949 system that supports hB should choose that as the most 1950 preferred format for the C (not the <code>preferred</code> 1951 value H).</p> 1952 <pre><hours preferred="H" allowed="hB H" regions="CD"/> 1953<hours preferred="H" allowed="hB hb h H" regions="KE MM TZ UG"/> 1954</pre>Some systems may not want to use B and b, even if preferred 1955for the locale, so for compatibility the <code>preferred</code> 1956value is limited to {H, h, K, k}, and is the option selected by the 1957‘j’ date symbol. Thus the <code>preferred</code> value may not be 1958the same as the first <code>allowed</code> value. 1959 <h3>4.5 <a name="Day_Period_Rule_Sets" href= 1960 "#Day_Period_Rule_Sets" id="Day_Period_Rule_Sets">Day Period 1961 Rule Sets</a></h3> 1962 <p class="dtd"><!ELEMENT dayPeriodRuleSet ( dayPeriodRules* 1963 ) ><br> 1964 <!ATTLIST dayPeriodRuleSet type NMTOKEN #IMPLIED ></p> 1965 <p class="dtd"><!ELEMENT dayPeriodRules (dayPeriodRule*) 1966 ><br> 1967 <!ATTLIST dayPeriodRules locales NMTOKENS #REQUIRED ></p> 1968 <p class="dtd"><!ELEMENT dayPeriodRule EMPTY ><br> 1969 <!ATTLIST dayPeriodRule type NMTOKEN #REQUIRED ><br> 1970 <!ATTLIST dayPeriodRule at NMTOKEN #IMPLIED ><br> 1971 <!ATTLIST dayPeriodRule from NMTOKEN #IMPLIED ><br> 1972 <!ATTLIST dayPeriodRule before NMTOKEN #IMPLIED ><br></p> 1973 <p>Each locale can have a set of day period rules, which 1974 determine the periods during a day for use in time formats like 1975 "10:00 at night", or to select statements like "Your email 1976 arrived last night." If locales do not have dayPeriodRules, the 1977 computation of dayPeriods falls back to AM/PM.</p> 1978 <p>There are two kinds of dayPeriodRuleSets, based on the 1979 type:</p> 1980 <p>The <strong><em>format</em></strong> type is used in 1981 conjunction with times, such as to express "3:00 in the 1982 afternoon", or "12:00 noon". Many languages do not normally use 1983 terms that match AM/PM for such times, instead breaking up the 1984 day into more periods.</p> 1985 <p>The <strong>stand-alone</strong> type is used for selecting 1986 a period of the day for a general time associated with an 1987 event. For example, it can be used to select a message 1988 like:</p> 1989 <p class='xmlExample'><msg ... ><br> 1990 {day_period, select,<br> 1991 MORNING1 {Your email arrived yesterday morning.}<br> 1992 AFTERNOON1 {Your email arrived yesterday afternoon.}<br> 1993 EVENING1 {Your email arrived yesterday evening.}<br> 1994 NIGHT1 {Your email arrived last night.}<br> 1995 other {Your email arrived yesterday.}<br> 1996 ...<br> 1997 }<br> 1998 </msg></p> 1999 <p>The translated values for the selection 2000 (<strong>stand-alone</strong>) day periods are intended for use 2001 in designating a time of day, without an hour value.</p> 2002 <p>These are relative times within a single day. If the event 2003 can occur on multiple days, then that needs to be handled at a 2004 higher level.</p> 2005 <p>As with plurals, the exact set of periods used for any 2006 language may be different. It is the responsibility of any 2007 translation software to pick the relevant day periods for the 2008 locale for display to the translator (and end user).</p> 2009 <h4>4.5.1 <a name="Day_Period_Rules" href="#Day_Period_Rules" 2010 id="Day_Period_Rules">Day Period Rules</a></h4> 2011 <p>Here are the requirements for a rule set.</p> 2012 <h5><a name="Fixed_periods" href="#Fixed_periods" id= 2013 "Fixed_periods">4.5.1.1 Fixed periods</a></h5>There are 4 2014 dayPeriods that are fixed; am/pm are always defined, and always 2015 have the same meaning and definition for every locale. Midnight 2016 and noon are optional, however if they are defined, they have 2017 the same meaning and definition as in all other locales where 2018 they are defined. 2019 <pre><dayPeriodRule type="midnight" at="00:00"/> 2020<dayPeriodRule type="am" from="00:00" before="12:00" /> 2021<dayPeriodRule type="noon" at="12:00"/> 2022<dayPeriodRule type="pm" from="12:00" before="24:00" /> 2023</pre> 2024 <p>Note that midnight and am can overlap, as can noon and 2025 pm.<br></p> 2026 <p>All locales must support am/pm, but not all support 2027 <strong>noon</strong> or <strong>midnight</strong>; they are 2028 only supported if they meet the above definitions. For example, 2029 German has no unique term that means exactly 12:00 noon; the 2030 closest is Mittag, but that can extend before or after 12 2031 noon.</p> 2032 <p><strong>Midnight</strong> is also special, since it can 2033 refer to either 00:00 or 24:00 — either at the start or end of 2034 the day. That means that Tuesday 24:00 = Wednesday 00:00. 2035 “Midnight Tuesday" is thus ambiguous: it means 24:00 in “the 2036 party is Tuesday from 10pm to 12 midnight”, while it means 2037 00:00 in “I was awake from 12 midnight to 3 in the 2038 morning”.</p> 2039 <p>It is strongly recommended that implementations provide for 2040 the ability to specify whether <strong>midnight</strong> is 2041 supported or not (and for either 00:00 or 24:00 or both), since 2042 only the caller knows enough of the context to determine what 2043 to use. In the absence of such information, 24:00 may be the 2044 best choice.<br></p> 2045 <h5><a name="Variable_periods" href="#Variable_periods" id= 2046 "Variable_periods">4.5.1.2 Variable periods</a></h5> 2047 <ol> 2048 <li>If a locale has a set of dayPeriodRules for variable 2049 periods, it needs to completely cover the 24 hours in a day 2050 (from 0:00 before 24:00), with 2051 <strong>no</strong> overlaps between 2052 any dayPeriodRules. They may overlap with the 2053 <strong>Fixed Periods</strong>.<br> 2054 If it does not have a rule set for variable periods, behavior 2055 should fall back to using the fixed periods (am, pm).</li> 2056 <li>"from" is a closed interval (inclusive). <em>(as is the 2057 deprecated "to")</em></li> 2058 <li>"before" is an open interval (exclusive). <em>(as is the 2059 deprecated "after")</em></li> 2060 <li>"at" means starting time and end time are the same. 2061 <em>("at" is deprecated except when used for the fixed 2062 periods)</em></li> 2063 <li>There must be exactly one of {at, from, after} and 2064 exactly one of {at, to, before} for 2065 each dayPeriodRule.</li> 2066 <li>Use of non-zero minutes or seconds is deprecated.</li> 2067 <li>The dayPeriodRules for format must allow that hh:mm 2068 [period name] and hh [period name] can be parsed uniquely to 2069 HH:mm [period name]. 2070 <ul> 2071 <li>For example, you can't have <dayPeriod type = 2072 "morning1" from="00:00" to="13:00"/> because "12:30 2073 {morning}" would be ambiguous.</li> 2074 </ul> 2075 </li> 2076 <li>There must not be two rules with the same type. A day 2077 period rule may, however, span 24:00 / 00:00. Example: 2078 <ul> 2079 <li> 2080 <em>Valid:</em> 2081 <ul> 2082 <li><dayPeriod type = "night1" from="21:00" 2083 to="05:00"/></li> 2084 </ul> 2085 </li> 2086 <li> 2087 <em>Invalid:</em> 2088 <ul> 2089 <li><dayPeriod type = "night1" from="00:00" 2090 to="05:00"/></li> 2091 <li><dayPeriod type = "night1" from="21:00" 2092 to="24:00"/></li> 2093 </ul> 2094 </li> 2095 </ul> 2096 </li> 2097 <li>24:00 is <em>only</em> allowed 2098 in <em>before</em>="24:00".</li> 2099 </ol> 2100 <h5><a name="Parsing_Day_Periods" href="#Parsing_Day_Periods" 2101 id="Parsing_Day_Periods">4.5.1.3 Parsing Day Periods</a></h5> 2102 <p>When parsing, if the hour is present with a strict parse the 2103 dayperiod is checked for consistency with the hour. If there is 2104 no hour, the center of the first 2105 matching dayPeriodRule can be chosen (starting 2106 from 0:00). However, if there is other information available 2107 when parsing, a different point within the interval may be 2108 chosen.</p> 2109 <p>The dayPeriodRule may span two days, such as where 2110 <strong>night1</strong> is [21:00, 06:00). In that case, the 2111 midpoint is 01:30, so when parsing “Nov 12, at night”, the 2112 midpoint result would be Nov 12, 01:30. “Nov 12, am”, “Nov 12, 2113 pm”, “Nov 12, noon” can be parsed similarly, resulting in Nov 2114 12, 06:00; Nov 12, 18:00; and Nov 12, 12:00; respectively.</p> 2115 <p>“Nov 12, midnight” is special, because midnight may mean 2116 either 00:00 or 24:00. Extra information may be needed to 2117 disambiguate which is meant, such as whether the time is at the 2118 start or end of an interval. In the absence of such 2119 information, 24:00 may be the best choice. See the discussion 2120 of <strong>midnight</strong> above.</p> 2121 <p>If rounding is done—including the rounding done by the time 2122 format—then it needs to be done before the dayperiod is 2123 computed, so that the correct format is shown.</p> 2124 <p>For examples, see <a href= 2125 "https://unicode-org.github.io/cldr-staging/charts/38/supplemental/day_periods.html"> 2126 Day Periods Chart</a>.</p> 2127 <h2>5 <a name="Time_Zone_Names" href="#Time_Zone_Names" id= 2128 "Time_Zone_Names">Time Zone Names</a></h2> 2129 <p class="dtd"><!ELEMENT timeZoneNames (alias | 2130 (hourFormat*, gmtFormat*, gmtZeroFormat*, regionFormat*, 2131 fallbackFormat*, zone*, metazone*, special*)) ></p> 2132 <p class="dtd"><!ELEMENT hourFormat ( #PCDATA ) ><br> 2133 <!ELEMENT gmtFormat ( #PCDATA ) ><br> 2134 <!ELEMENT gmtZeroFormat ( #PCDATA ) ></p> 2135 <p class="dtd"><!ELEMENT regionFormat ( #PCDATA ) ><br> 2136 <!ATTLIST regionFormat type ( standard | daylight ) #IMPLIED 2137 ></p> 2138 <p class="dtd"><!ELEMENT fallbackFormat ( #PCDATA ) ></p> 2139 <p class="dtd"><!ELEMENT zone (alias | ( long*, short*, 2140 exemplarCity*, special*)) ><br> 2141 <!ATTLIST zone type CDATA #REQUIRED ></p> 2142 <p class="dtd"><!ELEMENT metazone (alias | ( long*, short*, 2143 special*)) ><br> 2144 <!ATTLIST metazone type CDATA #REQUIRED ></p> 2145 <p class="dtd"><!ELEMENT long (alias | (generic*, standard*, 2146 daylight*, special*)) ><br> 2147 <!ELEMENT short (alias | (generic*, standard*, daylight*, 2148 special*)) ></p> 2149 <p class="dtd"><!ELEMENT generic ( #PCDATA ) ><br> 2150 <!ELEMENT standard ( #PCDATA ) ><br> 2151 <!ELEMENT daylight ( #PCDATA ) ></p> 2152 <p class="dtd"><!ELEMENT exemplarCity ( #PCDATA ) ></p> 2153 <p>The time zone IDs (tzid) are language-independent, and 2154 follow the <i>TZ time zone database</i> [<a href= 2155 "tr35.html#Olson">Olson</a>] and naming conventions. However, 2156 the display names for those IDs can vary by locale. The generic 2157 time is so-called <i>wall-time</i>; what clocks use when they 2158 are correctly switched from standard to daylight time at the 2159 mandated time of the year.</p> 2160 <p>Unfortunately, the canonical tzid's (those in zone.tab) are 2161 not stable: may change in each release of the <i>TZ</i> Time 2162 Zone database. In CLDR, however, stability of identifiers is 2163 very important. So the canonical IDs in CLDR are kept stable as 2164 described in <a href="tr35.html#Canonical_Form">Canonical 2165 Form</a>.</p> 2166 <p>The <i>TZ time zone database</i> can have multiple IDs that 2167 refer to the same entity. It does contain information on 2168 equivalence relationships between these IDs, such as 2169 "Asia/Calcutta" and "Asia/Kolkata". It does not remove IDs 2170 (with a few known exceptions), but it may change the 2171 "canonical" ID which is in the file zone.tab.</p> 2172 <p>For lookup purposes specifications such as CLDR need a 2173 stable canonical ID, one that does not change from release to 2174 release. The stable ID is maintained as the first alias item 2175 <i>type</i> element in the file bcp47/timezone.xml, such 2176 as:</p> 2177 <pre> 2178 <type name="inccu" alias="Asia/Calcutta Asia/Kolkata"/></pre> 2179 <p>That file also contains the short ID used in keywords. In 2180 versions of CLDR previous to 1.8, the alias information (but 2181 not the short ID) was in Supplemental Data under the zoneItem, 2182 such as:</p> 2183 <pre> 2184 <zoneItem type="Asia/Calcutta" territory="IN" aliases="Asia/Kolkata"/></pre> 2185 <p>This element was deprecated after the introduction of 2186 bcp47/timezone.xml, because the information became redundant 2187 (or was contained in the <i>TZ time zone database</i>).</p> 2188 <p>The following is an example of time zone data. Although this 2189 is an example of possible data, in most cases only the 2190 exemplarCity needs translation. And that does not even need to 2191 be present, if a country only has a single time one. As always, 2192 the <i>type</i> field for each zone is the identification of 2193 that zone. It is not to be translated.</p> 2194 <pre><zone type="<span style= 2195 "color: blue">America/Los_Angeles</span>"> 2196 <long> 2197 <generic><span style= 2198"color: blue">Pacific Time</span></generic> 2199 <standard><span style= 2200"color: blue">Pacific Standard Time</span></standard> 2201 <daylight><span style= 2202"color: blue">Pacific Daylight Time</span></daylight> 2203 </long> 2204 <short> 2205 <generic><span style= 2206"color: blue">PT</span></generic> 2207 <standard><span style= 2208"color: blue">PST</span></standard> 2209 <daylight><span style= 2210"color: blue">PDT</span></daylight> 2211 </short> 2212 <exemplarCity><span style= 2213"color: blue">San Francisco</span></exemplarCity> 2214</zone> 2215 2216<zone type="<span style="color: blue">Europe/London</span>"> 2217 <long> 2218 <generic><span style= 2219"color: blue">British Time</span></generic> 2220 <standard><span style= 2221"color: blue">British Standard Time</span></standard> 2222 <daylight><span style= 2223"color: blue">British Daylight Time</span></daylight> 2224 </long> 2225 <exemplarCity><span style= 2226"color: blue">York</span></exemplarCity> 2227</zone>\ 2228</pre> 2229 <p>In a few cases, some time zone IDs do not designate a city, 2230 as in:</p> 2231 <pre><zone type="<span style= 2232 "color: blue">America/Puerto_Rico</span>"> 2233 ... 2234</zone> 2235 2236<zone type="<span style="color: blue">America/Guyana</span>"> 2237 ... 2238</zone> 2239 2240<zone type="<span style="color: blue">America/Cayman</span>"> 2241 ... 2242</zone> 2243 2244<zone type="<span style= 2245"color: blue">America/St_Vincent</span>"> 2246 ... 2247</zone> 2248</pre> 2249 <p>They may designate countries or territories; their actual 2250 capital city may be a name that is too common, or, too 2251 uncommon. CLDR time zone IDs follow the <a href= 2252 "tr35.html#Olson">Olson</a> naming conventions.</p> 2253 <blockquote> 2254 <p class="note"><b>Note:</b> CLDR does not allow "GMT", "UT", 2255 or "UTC" as translations (short or long) of time zones other 2256 than GMT itself.</p> 2257 </blockquote> 2258 <blockquote> 2259 <p class="note"><b>Note:</b> Transmitting "14:30" with no 2260 other context is incomplete unless it contains information 2261 about the time zone. Ideally one would transmit 2262 neutral-format date/time information, commonly in UTC (GMT), 2263 and localize as close to the user as possible. (For more 2264 about UTC, see [<a href= 2265 "tr35.html#UTCInfo">UTCInfo</a>].)</p> 2266 </blockquote> 2267 <p class="note">The conversion from local time into UTC depends 2268 on the particular time zone rules, which will vary by location. 2269 The standard data used for converting local time (sometimes 2270 called <i>wall time</i>) to UTC and back is the <i>TZ Data</i> 2271 [<a href="tr35.html#Olson">Olson</a>], used by Linux, UNIX, 2272 Java, ICU, and others. The data includes rules for matching the 2273 laws for time changes in different countries. For example, for 2274 the US it is:</p> 2275 <blockquote> 2276 <p>"During the period commencing at 2 o'clock antemeridian on 2277 the second Sunday of March of each year and ending at 2 2278 o'clock antemeridian on the first Sunday of November of each 2279 year, the standard time of each zone established by sections 2280 261 to 264 of this title, as modified by section 265 of this 2281 title, shall be advanced one hour..." (United States Law - 15 2282 U.S.C. §6(IX)(260-7), as amended by Energy Policy Act of 2283 2005).</p> 2284 </blockquote> 2285 <p class="note">Each region that has a different time zone or 2286 daylight savings time rules, either now or at any time back to 2287 1970, is given a unique internal ID, such as 2288 <code>Europe/Paris</code> . (Some IDs are also distinguished on 2289 the basis of differences before 1970.) As with currency codes, 2290 these are internal codes. A localized string associated with 2291 these is provided for users (such as in the Windows <i>Control 2292 Panels>Date/Time>Time Zone</i>).</p> 2293 <p class="note">Unfortunately, laws change over time, and will 2294 continue to change in the future, both for the boundaries of 2295 time zone regions and the rules for daylight savings. Thus the 2296 <i>TZ</i> data is continually being augmented. Any two 2297 implementations using the same version of the <i>TZ</i> data 2298 will get the same results for the same IDs (assuming a correct 2299 implementation). However, if implementations use different 2300 versions of the data they may get different results. So if 2301 precise results are required then both the <i>TZ</i> ID and the 2302 <i>TZ</i> data version must be transmitted between the 2303 different implementations.</p> 2304 <p class="note">For more information, see [<a href= 2305 "tr35.html#DataFormats">Data Formats</a>].</p> 2306 <p>The following subelements of <timeZoneNames> are used 2307 to control the fallback process described in <a href= 2308 "#Using_Time_Zone_Names">Using Time Zone Names</a>.</p> 2309 <table cellspacing="0" cellpadding="4" border="1"> 2310 <caption> 2311 <a name="timeZoneNames_Elements_Used_for_Fallback" href= 2312 "#timeZoneNames_Elements_Used_for_Fallback" id= 2313 "timeZoneNames_Elements_Used_for_Fallback"><timeZoneNames> 2314 Elements Used for Fallback</a> 2315 </caption> 2316 <tr> 2317 <th>Element Name</th> 2318 <th>Data Examples</th> 2319 <th>Results/Comment</th> 2320 </tr> 2321 <tr> 2322 <td rowspan="2">hourFormat</td> 2323 <td rowspan="2">"+HHmm;-HHmm"</td> 2324 <td>"+1200"</td> 2325 </tr> 2326 <tr> 2327 <td>"-1200"</td> 2328 </tr> 2329 <tr> 2330 <td rowspan="2">gmtFormat</td> 2331 <td>"GMT{0}"</td> 2332 <td>"GMT-0800"</td> 2333 </tr> 2334 <tr> 2335 <td>"{0}ВпГ"</td> 2336 <td>"-0800ВпГ"</td> 2337 </tr> 2338 <tr> 2339 <td>gmtZeroFormat</td> 2340 <td>"GMT"</td> 2341 <td>Specifies how GMT/UTC with no explicit offset (implied 2342 0 offset) should be represented.</td> 2343 </tr> 2344 <tr> 2345 <td rowspan="2">regionFormat</td> 2346 <td>"{0} Time"</td> 2347 <td>"Japan Time"</td> 2348 </tr> 2349 <tr> 2350 <td>"Hora de {0}"</td> 2351 <td>"Hora de Japón"</td> 2352 </tr> 2353 <tr> 2354 <td rowspan="2">regionFormat type="daylight"<br> 2355 (or "standard")</td> 2356 <td>"{0} Daylight Time"</td> 2357 <td>"France Daylight Time"</td> 2358 </tr> 2359 <tr> 2360 <td>"horario de verano de {0}"</td> 2361 <td>"horario de verano de Francia"</td> 2362 </tr> 2363 <tr> 2364 <td>fallbackFormat</td> 2365 <td>"{1} ({0})"</td> 2366 <td>"Pacific Time (Canada)"</td> 2367 </tr> 2368 </table> 2369 <p>When referring to the abbreviated (short) form of the time 2370 zone name, there are often situations where the location-based 2371 (city or country) time zone designation for a particular 2372 language may not be in common usage in a particular 2373 territory.</p> 2374 <blockquote> 2375 <p class="note"><b>Note:</b> User interfaces for time zone 2376 selection can use the "generic location format" for time zone 2377 names to obtain the most useful ordering of names in a menu 2378 or list; see <i><a href="#Using_Time_Zone_Names">Using Time 2379 Zone Names</a></i> and the zone section of the <i><a href= 2380 "#Date_Field_Symbol_Table">Date Field Symbol 2381 Table</a>.</i></p> 2382 </blockquote> 2383 <h3>5.1 <a name="Metazone_Names" href="#Metazone_Names" id= 2384 "Metazone_Names">Metazone Names</a></h3> 2385 <p>A metazone is an grouping of one or more internal TZIDs that 2386 share a common display name in current customary usage, or that 2387 have shared a common display name during some particular time 2388 period. For example, the zones <i>Europe/Paris, Europe/Andorra, 2389 Europe/Tirane, Europe/Vienna, Europe/Sarajevo, Europe/Brussels, 2390 Europe/Zurich, Europe/Prague, Europe/Berlin</i>, and so on are 2391 often simply designated <i>Central European Time</i> (or 2392 translated equivalent).</p> 2393 <p>A metazone's display fields become a secondary fallback if 2394 an appropriate data field cannot be found in the explicit time 2395 zone data. The <i>usesMetazone</i> field indicates that the 2396 target metazone is active for a particular time. This also 2397 provides a mechanism to effectively deal with situations where 2398 the time zone in use has changed for some reason. For example, 2399 consider the TZID "America/Indiana/Knox", which observed 2400 Central time (GMT-6:00) prior to October 27, 1991, and has 2401 currently observed Central time since April 2, 2006, but has 2402 observed Eastern time ( GMT-5:00 ) between these two dates. 2403 This is denoted as follows</p> 2404 <pre><timezone type="America/Indiana/Knox"> 2405 <usesMetazone to="1991-10-27 07:00" mzone="America_Central"/> 2406 <usesMetazone to="2006-04-02 07:00" from="1991-10-27 07:00" mzone="America_Eastern"/> 2407 <usesMetazone from="2006-04-02 07:00" mzone="America_Central"/> 2408</timezone></pre> 2409 <p>Note that the dates and times are specified in UTC, not 2410 local time.</p> 2411 <p>The metazones can then have translations in different locale 2412 files, such as the following.</p> 2413 <pre><metazone type="America_Central"> 2414 <long> 2415 <generic>Central Time</generic> 2416 <standard>Central Standard Time</standard> 2417 <daylight>Central Daylight Time</daylight> 2418 </long> 2419 <short> 2420 <generic>CT</generic> 2421 <standard>CST</standard> 2422 <daylight>CDT</daylight> 2423 </short> 2424</metazone> 2425<metazone type="America_Eastern"> 2426 <long> 2427 <generic>Eastern Time</generic> 2428 <standard>Eastern Standard Time</standard> 2429 <daylight>Eastern Daylight Time</daylight> 2430 </long> 2431 <short> 2432 <generic>ET</generic> 2433 <standard>EST</standard> 2434 <daylight>EDT</daylight> 2435 </short> 2436</metazone></pre> 2437 <pre><metazone type="America_Eastern"> 2438 <long> 2439 <generic>Heure de l’Est</generic> 2440 <standard>Heure normale de l’Est</standard> 2441 <daylight>Heure avancée de l’Est</daylight> 2442 </long> 2443 <short> 2444 <generic>HE</generic> 2445 <standard>HNE</standard> 2446 <daylight>HAE</daylight> 2447 </short> 2448</metazone> 2449</pre> 2450 <p>When formatting a date and time value using this data, an 2451 application can properly be able to display "Eastern Time" for 2452 dates between 1991-10-27 and 2006-04-02, but display "Central 2453 Time" for current dates. (See also <i><a href= 2454 "tr35.html#Date_Ranges">Dates and Date Ranges</a></i>).</p> 2455 <p>Metazones are used with the 'z', 'zzzz', 'v', and 'vvvv date 2456 time pattern characters, and not with the 'Z', 'ZZZZ', 'VVVV' 2457 and other pattern characters for time zone formatting. For more 2458 information, see <a href="#Date_Format_Patterns"><u>Date Format 2459 Patterns</u></a> .</p> 2460 <p>The commonlyUsed element is now deprecated. The CLDR 2461 committee has found it nearly impossible to obtain accurate and 2462 reliable data regarding which time zone abbreviations may be 2463 understood in a given territory, and therefore has changed to a 2464 simpler approach. Thus, if the short metazone form is available 2465 in a given locale, it is to be used for formatting regardless 2466 of the value of commonlyUsed. If a given short metazone form is 2467 known NOT to be understood in a given locale and the parent 2468 locale has this value such that it would normally be inherited, 2469 the inheritance of this value can be explicitly disabled by use 2470 of the 'no inheritance marker' as the value, which is 3 2471 simultaneous empty set characters ( U+2205 ).</p> 2472 <h2>6 <a name="Supplemental_Time_Zone_Data" href= 2473 "#Supplemental_Time_Zone_Data" id= 2474 "Supplemental_Time_Zone_Data">Supplemental Time Zone 2475 Data</a></h2> 2476 <h3>6.1 <a name="Metazones" href="#Metazones" id= 2477 "Metazones">Metazones</a></h3> 2478 <p class="dtd"><!ELEMENT metaZones (metazoneInfo?, 2479 mapTimezones?) ><br></p> 2480 <p class="dtd"><!ELEMENT metazoneInfo (timezone*) ></p> 2481 <p class="dtd"><!ELEMENT timezone (usesMetazone*) ><br> 2482 <!ATTLIST timezone type CDATA #REQUIRED ></p> 2483 <p class="dtd"><!ELEMENT usesMetazone EMPTY ><br> 2484 <!ATTLIST usesMetazone mzone NMTOKEN #REQUIRED ><br> 2485 <!ATTLIST usesMetazone from CDATA #IMPLIED ><br> 2486 <!ATTLIST usesMetazone to CDATA #IMPLIED ></p> 2487 <p class="dtd"><!ELEMENT mapTimezones ( mapZone* ) ><br> 2488 <!ATTLIST mapTimezones type NMTOKEN #IMPLIED ><br> 2489 <!ATTLIST mapTimezones typeVersion CDATA #IMPLIED ><br> 2490 <!ATTLIST mapTimezones otherVersion CDATA #IMPLIED ><br> 2491 <!ATTLIST mapTimezones references CDATA #IMPLIED ></p> 2492 <p class="dtd"><!ELEMENT mapZone EMPTY ><br> 2493 <!ATTLIST mapZone type CDATA #REQUIRED ><br> 2494 <!ATTLIST mapZone other CDATA #REQUIRED ><br> 2495 <!ATTLIST mapZone territory CDATA #IMPLIED ><br> 2496 <!ATTLIST mapZone references CDATA #IMPLIED ></p> 2497 <p>The following subelement of <metaZones> provides a 2498 mapping from a single Unicode time zone id to metazones. For 2499 more information about metazones, See <i><a href= 2500 "tr35-dates.html#Time_Zone_Names">Time Zone Names</a></i>.</p> 2501 <pre><metazoneInfo> 2502 <timezone type="Europe/Andorra"> 2503 <usesMetazone mzone="Europe_Central"/> 2504 </timezone> 2505 .... 2506 <timezone type="Asia/Yerevan"> 2507 <usesMetazone to="1991-09-22 20:00" mzone="Yerevan"/> 2508 <usesMetazone from="1991-09-22 20:00" mzone="Armenia"/> 2509 </timezone> 2510 .... 2511</pre> 2512 <p>The following subelement of <metaZones> specifies a 2513 mapping from a metazone to golden zones for each territory. For 2514 more information about golden zones, see <i><a href= 2515 "tr35-dates.html#Using_Time_Zone_Names">Using Time Zone 2516 Names</a></i>.</p> 2517 <pre><mapTimezones type="metazones"> 2518 <mapZone other="Acre" territory="001" type="America/Rio_Branco"/> 2519 <mapZone other="Afghanistan" territory="001" type="Asia/Kabul"/> 2520 <mapZone other="Africa_Central" territory="001" type="Africa/Maputo"/> 2521 <mapZone other="Africa_Central" territory="BI" type="Africa/Bujumbura"/> 2522 <mapZone other="Africa_Central" territory="BW" type="Africa/Gaborone"/> 2523 .... 2524</pre> 2525 <h3>6.2 <a name="Windows_Zones" href="#Windows_Zones" id= 2526 "Windows_Zones">Windows Zones</a></h3> 2527 <p class="dtd"><!ELEMENT windowsZones (mapTimezones?) 2528 ></p> 2529 <p>The <mapTimezones> element can be also used to provide 2530 mappings between Unicode time zone IDs and other time zone IDs. 2531 This example specifies a mapping from Windows TZIDs to Unicode 2532 time zone IDs .</p> 2533 <pre> 2534 <mapTimezones otherVersion="07dc0000" typeVersion="2011n"> 2535 .... 2536 <!-- (UTC-08:00) Baja California --> 2537 <mapZone other="Pacific Standard Time (Mexico)" territory="001" type="America/Santa_Isabel"/> 2538 <mapZone other="Pacific Standard Time (Mexico)" territory="MX" type="America/Santa_Isabel"/> 2539 2540 <!-- (UTC-08:00) Pacific Time (US & Canada) --> 2541 <mapZone other="Pacific Standard Time" territory="001" type="America/Los_Angeles"/> 2542 <mapZone other="Pacific Standard Time" territory="CA" type="America/Vancouver America/Dawson America/Whitehorse"/> 2543 <mapZone other="Pacific Standard Time" territory="MX" type="America/Tijuana"/> 2544 <mapZone other="Pacific Standard Time" territory="US" type="America/Los_Angeles"/> 2545 <mapZone other="Pacific Standard Time" territory="ZZ" type="PST8PDT"/> 2546 .... 2547</pre> 2548 <p>The attributes otherVersion and typeVersion in 2549 <mapTimezones> specify the versions of two systems. In 2550 the example above, otherVersion="07dc0000" specifies the 2551 version of Windows time zone and typeVersion="2011n" specifies 2552 the version of Unicode time zone IDs. The attribute 2553 territory="001" in <mapZone> element indicates the long 2554 canonical Unicode time zone ID specified by the type attribute 2555 is used as the default mapping for the Windows TZID. For each 2556 unique Windows TZID, there must be exactly one <mapZone> 2557 element with territory="001". <mapZone> elements other 2558 than territory="001" specify territory specific mappings. When 2559 multiple Unicode time zone IDs are available for a single 2560 territory, the value of the type attribute will be a list of 2561 Unicode time zone IDs delimited by space. In this case, the 2562 first entry represents the default mapping for the territory. 2563 The territory "ZZ" is used when a Unicode time zone ID is not 2564 associated with a specific territory.</p> 2565 <p><b>Note:</b> The long canonical Unicode time zone ID might 2566 be deprecated in the tz database[<a href= 2567 "tr35.html#Olson">Olson</a>]. For example, CLDR uses 2568 "Asia/Culcutta" as the long canonical time zone ID for Kolkata, 2569 India. The same ID was moved to 'backward' file and replaced 2570 with a new ID "Asia/Kolkata" in the tz database. Therefore, if 2571 you want to get an equivalent Windows TZID for a zone ID in the 2572 tz dadtabase, you have to resolve the long canonical Unicode 2573 time zone ID (e.g. "Asia/Culcutta") for the zone ID (e.g. 2574 "Asia/Kolkata"). For more details, see <a href= 2575 "tr35.html#Time_Zone_Identifiers">Section 3.7.1.2 Time Zone 2576 Identifiers</a>.</p> 2577 <p><b>Note:</b> Not all Unicode time zones have equivalent 2578 Windows TZID mappings. Also, not all Windows TZIDs have 2579 equivalent Unicode time zones. For example, there is no 2580 equivalent Windows zone for Unicode time zone 2581 "Australia/Lord_Howe", and there is no equivalent Unicode time 2582 zone for Windows zone "E. Europe Standard Time" (as of CLDR 25 2583 release).</p> 2584 <h3>6.3 <a name="Primary_Zones" href="#Primary_Zones" id= 2585 "Primary_Zones">Primary Zones</a></h3> 2586 <p class="dtd"><!ELEMENT primaryZones ( primaryZone* ) 2587 ><br> 2588 <!ELEMENT primaryZone ( #PCDATA ) ><br> 2589 <!ATTLIST primaryZone iso3166 NMTOKEN #REQUIRED ></p> 2590 <p>This element is for data that is used to format a time 2591 zone’s generic location name. Each <primaryZone> element 2592 specifies the dominant zone for a region; this zone should use 2593 the region name for its generic location name even though there 2594 are other canonical zones available in the same region. For 2595 example, Asia/Shanghai is displayed as "China Time", instead of 2596 "Shanghai Time". Sample data:</p> 2597 <pre><primaryZones> 2598 <primaryZone iso3166="CL">America/Santiago</primaryZone> 2599 <primaryZone iso3166="CN">Asia/Shanghai</primaryZone> 2600 <primaryZone iso3166="DE">Europe/Berlin</primaryZone> 2601 … 2602</pre> 2603 <p>This information was previously specified by the LDML 2604 <singleCountries> element under each locale’s 2605 <timeZoneNames> element. However, that approach had 2606 inheritance issues, and the data is not really locale-specific 2607 anyway.</p> 2608 <h2>7 <a name="Using_Time_Zone_Names" href= 2609 "#Using_Time_Zone_Names" id="Using_Time_Zone_Names">Using Time 2610 Zone Names</a></h2> 2611 <p>There are three main types of formats for zone identifiers: 2612 GMT, generic (wall time), and standard/daylight. Standard and 2613 daylight are equivalent to a particular offset from GMT, and 2614 can be represented by a GMT offset as a fallback. In general, 2615 this is not true for the generic format, which is used for 2616 picking timezones or for conveying a timezone for specifying a 2617 recurring time (such as a meeting in a calendar). For either 2618 purpose, a GMT offset would lose information.</p> 2619 <h3>7.1 <a name="Time_Zone_Format_Terminology" href= 2620 "#Time_Zone_Format_Terminology" id= 2621 "Time_Zone_Format_Terminology">Time Zone Format 2622 Terminology</a></h3> 2623 <p>The following terminology defines more precisely the formats 2624 that are used.</p> 2625 <p><b>Generic non-location format:</b> Reflects "wall time" 2626 (what is on a clock on the wall): used for recurring events, 2627 meetings, or anywhere people do not want to be overly specific. 2628 For example, "10 am Pacific Time" will be GMT-8 in the winter, 2629 and GMT-7 in the summer.</p> 2630 <ul> 2631 <li>"Pacific Time" (long)</li> 2632 <li>"PT" (short)</li> 2633 </ul> 2634 <p><b>Generic partial location format:</b> Reflects "wall 2635 time": used as a fallback format when the generic non-location 2636 format is not specific enough.</p> 2637 <ul> 2638 <li>"Pacific Time (Canada)" (long)</li> 2639 <li>"PT (Whitehorse)" (short)</li> 2640 </ul> 2641 <p><b>Generic location format:</b> Reflects "wall time": a 2642 primary function of this format type is to represent a time 2643 zone in a list or menu for user selection of time zone. It is 2644 also a fallback format when there is no translation for the 2645 generic non-location format. Times can also be organized 2646 hierarchically by country for easier lookup.</p> 2647 <blockquote> 2648 <p>France Time<br> 2649 Italy Time<br> 2650 Japan Time<br> 2651 United States<br> 2652 Chicago Time<br> 2653 Denver Time<br> 2654 Los Angeles Time<br> 2655 New York Time<br> 2656 United Kingdom Time</p> 2657 </blockquote> 2658 <p>Note: A generic location format is constructed by a part of 2659 time zone ID representing an exemplar city name or its country 2660 as the final fallback. However, there are Unicode time zones 2661 which are not associated with any locations, such as 2662 "Etc/GMT+5" and "PST8PDT". Although the date format pattern 2663 "VVVV" specifies the generic location format, but it displays 2664 localized GMT format for these. Some of these time zones 2665 observe daylight saving time, so the result (localized GMT 2666 format) may change depending on input date. For generating a 2667 list for user selection of time zone with format "VVVV", these 2668 non-location zones should be excluded.</p> 2669 <p><b>Specific non-location format:</b> Reflects a specific 2670 standard or daylight time, which may or may not be the wall 2671 time. For example, "10 am Pacific Standard Time" will be GMT-8 2672 in the winter and in the summer.</p> 2673 <ul> 2674 <li>"Pacific Standard Time" (long)</li> 2675 <li>"PST" (short)</li> 2676 <li>"Pacific Daylight Time" (long)</li> 2677 <li>"PDT" (short)</li> 2678 </ul> 2679 <p><b>Localized GMT format:</b> A constant, specific offset 2680 from GMT (or UTC), which may be in a translated form. There are 2681 two styles for this. The first is used when there is an 2682 explicit non-zero offset from GMT; this style is specified by 2683 the <gmtFormat> element and <hourFormat> element. 2684 The long format always uses 2-digit hours field and minutes 2685 field, with optional 2-digit seconds field. The short format is 2686 intended for the shortest representation and uses hour fields 2687 without leading zero, with optional 2-digit minutes and seconds 2688 fields. The digits used for hours, minutes and seconds fields 2689 in this format are the locale's default decimal digits:</p> 2690 <ul> 2691 <li>"GMT+03:30" (long)</li> 2692 <li>"GMT+3:30" (short)</li> 2693 <li>"UTC-03.00" (long)</li> 2694 <li>"UTC-3" (short)</li> 2695 <li>"Гриинуич+03:30" (long)</li> 2696 </ul> 2697 <p>Otherwise (when the offset from GMT is zero, referring to 2698 GMT itself) the style specified by the <gmtZeroFormat> 2699 element is used:</p> 2700 <ul> 2701 <li>"GMT"</li> 2702 <li>"UTC"</li> 2703 <li>"Гриинуич"</li> 2704 </ul> 2705 <p><b>ISO 8601 time zone formats:</b> The formats based on the 2706 [<a href="tr35.html#ISO8601">ISO 8601</a>] local time 2707 difference from UTC ("+" sign is used when local time offset is 2708 0), or the UTC indicator ("Z" - only when the local time offset 2709 is 0 and the specifier X* is used). The ISO 8601 basic format 2710 does not use a separator character between hours and minutes 2711 field, while the extended format uses colon (':') as the 2712 separator. The ISO 8601 basic format with hours and minutes 2713 fields is equivalent to RFC 822 zone format.</p> 2714 <ul> 2715 <li>"-0800" (basic)</li> 2716 <li>"-08" (basic - short)</li> 2717 <li>"-08:00" (extended)</li> 2718 <li>"Z" (UTC)</li> 2719 </ul> 2720 <blockquote> 2721 <p class="note">Note: This specification extends the original 2722 ISO 8601 formats and some format specifiers append seconds 2723 field when necessary.</p> 2724 </blockquote> 2725 <p><b>Raw Offset</b> - an offset from GMT that does not include 2726 any daylight savings behavior. For example, the raw offset for 2727 Pacific Time is -8, even though the <i>observed offset</i> may 2728 be -8 or -7.</p> 2729 <p><b>Metazone</b> - a collection of time zones that share the 2730 same behavior and same name during some period. They may differ 2731 in daylight behavior (whether they have it and when).</p> 2732 <p>For example, the TZID America/Cambridge_Bay is in the 2733 following metazones during various periods:</p> 2734 <blockquote> 2735 <p><font size="2"><timezone 2736 type="America/Cambridge_Bay"><br> 2737 <usesMetazone to="1999-10-31 08:00" 2738 mzone="America_Mountain"/><br> 2739 <usesMetazone to="2000-10-29 07:00" from="1999-10-31 2740 08:00" mzone="America_Central"/><br> 2741 <usesMetazone to="2000-11-05 05:00" from="2000-10-29 2742 07:00" mzone="America_Eastern"/><br> 2743 <usesMetazone to="2001-04-01 09:00" from="2000-11-05 2744 05:00" mzone="America_Central"/><br> 2745 <usesMetazone from="2001-04-01 09:00" 2746 mzone="America_Mountain"/><br> 2747 </timezone></font></p> 2748 </blockquote> 2749 <p>Zones may join or leave a metazone over time. The data 2750 relating between zones and metazones is in the supplemental 2751 information; the locale data is restricted to translations of 2752 metazones and zones.</p> 2753 <blockquote> 2754 <b>Invariants:</b> 2755 <ul> 2756 <li>At any given point in time, each zone belongs to no 2757 more than one metazone.</li> 2758 <li>At a given point in time, a zone may not belong to any 2759 metazones.</li> 2760 <li><i>Except for daylight savings</i>, at any given time, 2761 all zones in a metazone have the same offset at that 2762 time.</li> 2763 </ul> 2764 </blockquote> 2765 <p><b>Golden Zone</b> - the TZDB zone that exemplifies a 2766 metazone. For example, America/New_York is the golden zone for 2767 the metazone America_Eastern:</p> 2768 <blockquote> 2769 <p><font size="2"><mapZone other="America_Eastern" 2770 territory="001" type="America/New_York"/></font></p> 2771 </blockquote> 2772 <blockquote> 2773 <b>Invariants:</b> 2774 <ul> 2775 <li style="margin-top: 0.5em; margin-bottom: 0.5em">The 2776 golden zones are those in mapZone supplemental data under 2777 the territory "001".</li> 2778 <li style="margin-top: 0.5em; margin-bottom: 0.5em">Every 2779 metazone has exactly one golden zone.</li> 2780 <li style="margin-top: 0.5em; margin-bottom: 0.5em">Each 2781 zone has at most one metazone for which it is golden.</li> 2782 <li style="margin-top: 0.5em; margin-bottom: 0.5em">The 2783 golden zone is in that metazone during the entire life of 2784 the metazone. (The raw offset of the golden zone may change 2785 over time.)</li> 2786 <li>Each other zone must have the same raw offset as the 2787 golden zone, for the entire period that it is in the 2788 metazone. (It might not have the same offset when daylight 2789 savings is in effect.)</li> 2790 <li>A golden zone in mapTimezones must have reverse mapping 2791 in metazoneInfo.</li> 2792 <li>A single time zone can be a golden zone of multiple 2793 different metazones if any two of them are never active at 2794 a same time.</li> 2795 </ul> 2796 </blockquote> 2797 <p><b>Preferred Zone</b> - for a given TZID, the "best" zone 2798 out of a metazone for a given country or language.</p> 2799 <blockquote> 2800 <b>Invariants:</b> 2801 <ul> 2802 <li>The preferred zone for a given country XX are those in 2803 mapZone supplemental data under the territory XX.</li> 2804 <li style="margin-top: 0.5em; margin-bottom: 0.5em">Every 2805 metazone has at most one preferred zone for a given 2806 territory XX.</li> 2807 <li style="margin-top: 0.5em; margin-bottom: 0.5em">Each 2808 zone has at most one metazone for which it is preferred for 2809 a territory XX.</li> 2810 <li style="margin-top: 0.5em; margin-bottom: 0.5em">The 2811 preferred zone for a given metazone and territory XX is in 2812 a metazone M during any time when any other zone in XX is 2813 also in M</li> 2814 <li style="margin-top: 0.5em; margin-bottom: 0.5em">A 2815 preferred zone in mapTimezones must have reverse mapping in 2816 metazoneInfo</li> 2817 </ul> 2818 </blockquote> 2819 <p>For example, for America_Pacific the preferred zone for 2820 Canada is America/Vancouver, and the preferred zone for Mexico 2821 is America/Tijuana. The golden zone is America/Los_Angeles, 2822 which is also also the preferred zone for any other 2823 country.</p> 2824 <blockquote> 2825 <p><font size="2"><mapZone other="America_Pacific" 2826 territory="001" type="America/Los_Angeles"/><br> 2827 <mapZone other="America_Pacific" territory="CA" 2828 type="America/Vancouver"/><br> 2829 <mapZone other="America_Pacific" territory="MX" 2830 type="America/Tijuana"/></font></p> 2831 </blockquote> 2832 <p><a name="fallbackFormat" href="#fallbackFormat" id= 2833 "fallbackFormat"><b>fallbackFormat</b>:</a> a formatting string 2834 such as "{1} ({0})", where {1} is the metazone, and {0} is the 2835 country or city.</p> 2836 <p><b>regionFormat:</b> a formatting string such as "{0} Time", 2837 where {0} is the country or city.</p> 2838 <h3>7.2 <a name="Time_Zone_Goals" href="#Time_Zone_Goals" id= 2839 "Time_Zone_Goals">Goals</a></h3> 2840 <p>The timezones are designed so that:</p> 2841 <blockquote> 2842 <p>For any given locale, every <i>time</i> round trips with 2843 all patterns (but not necessarily every timezone). That is, 2844 given a time and a format pattern with a zone string, you can 2845 format, then parse, and get back the same time.</p> 2846 <p>Note that the round-tripping is not just important for 2847 parsing; it provides for formatting dates and times in an 2848 unambiguous way for users. It is also important for 2849 testing.<br> 2850 <br> 2851 There are exceptions to the above for transition times.</p> 2852 <ul> 2853 <li>With generic format, time zone ID or exemplar city 2854 name, during the transition when the local time maps to two 2855 possible GMT times. 2856 <ul> 2857 <li>For example, Java works as follows, favoring 2858 standard time:</li> 2859 <li>Source: Sun Nov 04 01:30:00 PDT 2007</li> 2860 <li>=> Formatted: "Sunday, November 4, 2007 1:30:00 2861 AM"</li> 2862 <li>=> Parsed: Sun Nov 04 01:30:00 PST 2007</li> 2863 </ul> 2864 </li> 2865 <li>When the timezone changes offset, say from GMT+4 to 2866 GMT+5, there can also be a gap.</li> 2867 </ul> 2868 <p>The V/VV/VVV/VVVV format will roundtrip not only the time, 2869 but the canonical timezone.</p> 2870 </blockquote> 2871 <p>When the data for a given format is not available, a 2872 fallback format is used. The fallback order is given in the 2873 following by a list.</p> 2874 <ol> 2875 <li> 2876 <b>Specifics</b> 2877 <ul> 2878 <li>z - [short form] specific non-location 2879 <ul> 2880 <li>falling back to short localized GMT</li> 2881 </ul> 2882 </li> 2883 <li>zzzz - [long form] specific non-location 2884 <ul> 2885 <li>falling back to long localized GMT</li> 2886 </ul> 2887 </li> 2888 <li>Z/ZZZZZ/X+/x+ - ISO 8601 formats (no fallback 2889 necessary)</li> 2890 <li>ZZZZ/O+ - Localized GMT formats (no fallback 2891 necessary)</li> 2892 </ul> 2893 </li> 2894 <li> 2895 <b>Generics</b> 2896 <ul> 2897 <li>v - [short form] generic non-location<br> 2898 <i>(however, the rules are more complicated, see #5 2899 below)</i> 2900 <ul> 2901 <li>falling back to generic location</li> 2902 <li>falling back to short localized GMT</li> 2903 </ul> 2904 </li> 2905 <li>vvvv - [long form] generic non-location<br> 2906 <i>(however, the rules are more complicated, see #5 2907 below)</i> 2908 <ul> 2909 <li>falling back to generic location</li> 2910 <li>falling back to long localized GMT</li> 2911 </ul> 2912 </li> 2913 <li>V - short time zone ID 2914 <ul> 2915 <li>falling back to the special ID "unk" 2916 (Unknown)</li> 2917 </ul> 2918 </li> 2919 <li>VV - long time zone ID (no fallback necessary, 2920 because this is the input)</li> 2921 <li>VVV - exemplar city 2922 <ul> 2923 <li>falling back to the localized exemplar city for 2924 the unknown zone (Etc/Unknown), for example "Unknown 2925 City" for English</li> 2926 </ul> 2927 </li> 2928 <li>VVVV - generic location 2929 <ul> 2930 <li>falling back to long localized GMT</li> 2931 </ul> 2932 </li> 2933 </ul> 2934 </li> 2935 </ol> 2936 <p>The following process is used for the particular formats, 2937 with the fallback rules as above.</p> 2938 <p>Some of the examples are drawn from real data, while others 2939 are for illustration. For illustration the region format is 2940 "Hora de {0}". The fallback format in the examples is "{1} 2941 ({0})", which is what is in root.</p> 2942 <ol> 2943 <li>In <b>all</b> cases, first canonicalize the <i>TZ</i> ID 2944 according to the Unicode Locale Extension <i>type</i> mapping 2945 data (See <a href="tr35.html#Time_Zone_Identifiers">Time Zone 2946 Identifiers</a> for more details).. Use that canonical TZID 2947 in each of the following steps. 2948 <ul> 2949 <li>America/Atka → America/Adak</li> 2950 <li>Australia/ACT → Australia/Sydney</li> 2951 </ul> 2952 </li> 2953 <li style="margin-top: 0.5em; margin-bottom: 0.5em">For the 2954 localized GMT format, use the gmtFormat (such as "GMT{0}" or 2955 "HMG{0}") with the hourFormat (such as "+HH:mm;-HH:mm" or 2956 "+HH.mm;-HH.mm"). 2957 <ul> 2958 <li style="margin-top: 0.5em; margin-bottom: 0.5em"> 2959 America/Los_Angeles → "GMT-08:00" // standard time</li> 2960 <li style="margin-top: 0.5em; margin-bottom: 0.5em"> 2961 America/Los_Angeles → "HMG-07:00" // daylight time</li> 2962 <li style="margin-top: 0.5em; margin-bottom: 0.5em"> 2963 Etc/GMT+3 → "GMT-03.00" // note that <i>TZ</i> tzids have 2964 inverse polarity!</li> 2965 </ul> 2966 <p><b>Note:</b> The digits should be whatever are 2967 appropriate for the locale used to format the time zone, 2968 not necessarily from the western digits, 0..9. For example, 2969 they might be from ०..९.</p> 2970 </li> 2971 <li>For ISO 8601 time zone format return the results 2972 according to the ISO 8601 specification. 2973 <ul> 2974 <li>America/Los_Angeles → 2975 <ul> 2976 <li>"-08" ("X","x")</li> 2977 <li>"-0800" ("Z","XX","XXXX","xx","xxxx")</li> 2978 <li>"-08:00" 2979 ("ZZZZZ","XXX","XXXXX","xxx","xxxxx")</li> 2980 </ul> 2981 </li> 2982 <li>Etc/GMT → 2983 <ul> 2984 <li>"Z" ("ZZZZZ", "X", "XX", "XXX", "XXXX", 2985 "XXXXX")</li> 2986 <li>"+00" ("x")</li> 2987 <li>"+0000" ("Z", "xx", "xxxx")</li> 2988 <li>"+00:00" ("xxx", "xxxxx")</li> 2989 </ul> 2990 </li> 2991 </ul> 2992 <p><b>Note:</b> The digits in this case are always from the 2993 western digits, 0..9.</p> 2994 </li> 2995 <li>For the non-location formats (generic or specific): 2996 <ol> 2997 <li>if there is an explicit translation for the TZID in 2998 <timeZoneNames> according to type (generic, 2999 standard, or daylight) in the resolved locale, return it. 3000 <ol> 3001 <li>If the requested type is not available, but 3002 another type is, and there is a <strong>Type 3003 Fallback</strong> then return that other type. 3004 <ul> 3005 <li>Examples: 3006 <ul> 3007 <li>America/Los_Angeles → // generic</li> 3008 <li>America/Los_Angeles → "アメリカ太平洋標準時" // 3009 standard</li> 3010 <li>America/Los_Angeles → "Yhdysvaltain 3011 Tyynenmeren kesäaika" // daylight</li> 3012 <li>Europe/Dublin → "Am Samhraidh na 3013 hÉireann" // daylight</li> 3014 <li>Note: This translation may not at all be 3015 literal: it would be what is most 3016 recognizable for people using the target 3017 language.</li> 3018 </ul> 3019 </li> 3020 </ul> 3021 </li> 3022 </ol> 3023 </li> 3024 <li>Otherwise, get the requested metazone format 3025 according to type (generic, standard, daylight). 3026 <ol> 3027 <li>If the requested type is not available, but 3028 another type is, get the format according to 3029 <strong>Type Fallback</strong>.</li> 3030 <li>If there is no format for the type, fall 3031 back.</li> 3032 </ol> 3033 </li> 3034 <li>Otherwise do the following: 3035 <ol> 3036 <li>Get the country for the current locale. If there 3037 is none, use the most likely country based on the 3038 likelySubtags data. If there is none, use “001”.</li> 3039 <li>Get the preferred zone for the metazone for the 3040 country; if there is none for the country, use the 3041 preferred zone for the metazone for “001”.</li> 3042 <li>If that preferred zone is the same as the 3043 requested zone, use the metazone format. For example, 3044 "Pacific Time" for Vancouver if the locale is en_CA, 3045 or for Los Angeles if locale is en_US.</li> 3046 <li>Otherwise, if the zone is the preferred zone for 3047 its country but not for the country of the locale, 3048 use the metazone format + country in the 3049 <em>fallbackFormat</em>.</li> 3050 <li>Otherwise, use the metazone format + city in the 3051 <em>fallbackFormat</em>. 3052 <ul> 3053 <li>Examples: 3054 <ul> 3055 <li>"Pacific Time (Canada)" // for the zone 3056 Vancouver in the locale en_MX.</li> 3057 <li>"Mountain Time (Phoenix)"</li> 3058 <li>"Pacific Time (Whitehorse)"</li> 3059 </ul> 3060 </li> 3061 </ul> 3062 </li> 3063 </ol> 3064 </li> 3065 </ol> 3066 </li> 3067 <li>For the generic location format: 3068 <ol> 3069 <li>From the TZDB get the country code for the zone, and 3070 determine whether there is only one timezone in the 3071 country. If there is only one timezone or if the zone id 3072 is in the <primaryZones> list, format the country 3073 name with the <em>regionFormat</em>, and return it. 3074 <ul> 3075 <li>Examples: 3076 <ul> 3077 <li>Europe/Rome → IT → "Italy Time" // for 3078 English</li> 3079 <li>Asia/Shanghai → CN → "China Time" // 3080 Asia/Shanghai is the <em>primaryZone</em> for 3081 China</li> 3082 <li>Africa/Monrovia → LR → "Hora de Liberja"</li> 3083 <li>America/Havana → CU → "Hora de CU" // if CU 3084 is not localized</li> 3085 </ul> 3086 </li> 3087 </ul> 3088 </li> 3089 <li>Otherwise format the exemplar city with the 3090 <em>regionFormat</em>, and return it. 3091 <ol> 3092 <li>America/Buenos_Aires → "Buenos Aires Time"</li> 3093 </ol> 3094 </li> 3095 </ol> 3096 </li> 3097 </ol> 3098 <blockquote> 3099 <p><strong>Note:</strong> If a language does require 3100 grammatical changes when composing strings, then the 3101 <em>regionFormat</em> should either use a neutral format such 3102 as "Heure: {0}", or put all exceptional cases in explicitly 3103 translated strings.</p> 3104 </blockquote> 3105 <p><strong>Type Fallback</strong></p> 3106 <p>When a specified type (generic, standard, daylight) does not 3107 exist:</p> 3108 <ol> 3109 <li>If the daylight type does not exist, then the metazone 3110 doesn’t require daylight support. For all three types: 3111 <ol> 3112 <li>If the generic type exists, use it.</li> 3113 <li>Otherwise if the standard type exists, use it.</li> 3114 </ol> 3115 </li> 3116 <li>Otherwise if the generic type is needed, but not 3117 available, and the offset and daylight offset do not change 3118 within 184 day +/- interval around the exact formatted time, 3119 use the standard type. 3120 <ol> 3121 <li>Example: "Mountain Standard Time" for Phoenix</li> 3122 <li>Note: 184 is the smallest number that is at least 6 3123 months AND the smallest number that is more than 1/2 year 3124 (Gregorian).</li> 3125 </ol> 3126 </li> 3127 </ol> 3128 <p><strong>Composition</strong></p> 3129 <p>In composing the metazone + city or country:</p> 3130 <ol> 3131 <li>Use the <em>fallbackFormat</em> "{1} ({0})", where: 3132 <ul> 3133 <li>{1} will be the metazone</li> 3134 <li>{0} will be a qualifier (city or country)</li> 3135 <li>Example: 3136 <ul> 3137 <li>metazone = Pacific Time</li> 3138 <li>city = Phoenix</li> 3139 <li>→ "Pacific Time (Phoenix)"</li> 3140 </ul> 3141 </li> 3142 </ul> 3143 </li> 3144 <li>If the localized country name is not available, use the 3145 code: 3146 <ul> 3147 <li>CU (country code)→ "CU" <em>// no localized country 3148 name for Cuba</em></li> 3149 </ul> 3150 </li> 3151 <li>If the localized exemplar city is not available, use as 3152 the exemplar city the last field of the raw TZID, stripping 3153 off the prefix and turning _ into space. 3154 <ul> 3155 <li>America/Los_Angeles → "Los Angeles" <em>// no 3156 localized exemplar city</em></li> 3157 </ul> 3158 </li> 3159 </ol> 3160 <p><b>Note:</b> As with the <em>regionFormat</em>, exceptional 3161 cases need to be explicitly translated.</p> 3162 <h3>7.3 <a name="Time_Zone_Parsing" href="#Time_Zone_Parsing" 3163 id="Time_Zone_Parsing">Parsing</a></h3> 3164 <p>In parsing, an implementation will be able to either 3165 determine the zone id, or a simple offset from GMT for anything 3166 formatting according to the above process.</p> 3167 <p>The following is a sample process for how this might be 3168 done. It is only a sample; implementations may use different 3169 methods for parsing.</p> 3170 <p>The sample describes the parsing of a zone as if it were an 3171 isolated string. In implementations, the zone may be mixed in 3172 with other data (like the time), so the parsing actually has to 3173 look for the longest match, and then allow the remaining text 3174 to be parsed for other content. That requires certain adaptions 3175 to the following process.</p> 3176 <ol style="background-color: rgb(255, 255, 255);"> 3177 <li><font color="#000000">Start with a string S.</font></li> 3178 <li> 3179 <font color="#000000">If S matches ISO 8601 time zone 3180 format, return it.</font> 3181 <ul> 3182 <li>For example, "-0800" (RFC 822), "-08:00" (ISO 8601) 3183 => Etc/GMT+8</li> 3184 </ul> 3185 </li> 3186 <li>If S matches the English or localized GMT format, return 3187 the corresponding TZID 3188 <ul> 3189 <li>Matching should be lenient. Thus allow for the number 3190 formats like: 03, 3, 330, 3:30, 33045 or 3:30:45. Allow 3191 +, -, or nothing. Allow spaces after GMT, +/-, and before 3192 number. Allow non-Latin numbers. Allow UTC or UT (per RFC 3193 788) as synonyms for GMT ("GMT", "UT", "UTC" are global 3194 formats, always allowed in parsing regardless of 3195 locale).</li> 3196 <li>For example, "GMT+3" or "UT+3" or "HPG+3" => 3197 Etc/GMT-3</li> 3198 <li>When parsing, the absence of a numeric offset should 3199 be interpreted as offset 0, whether in localized or 3200 global formats. For example, "GMT" or "UT" or "UTC+0" or 3201 "HPG" => Etc/GMT</li> 3202 </ul> 3203 </li> 3204 <li> 3205 <font color="#000000">If S matches the fallback format, 3206 extract P = {0} [ie, the part in parens in the root format] 3207 and N = {1}.<br> 3208 If S does not match, set P = "" and N = S<br> 3209 If N matches the region format, then M = {0} from that 3210 format, otherwise M = N.</font> 3211 <ul> 3212 <li><font color="#000000">For example, "United States 3213 (Los Angeles) Time" => N = "United States Time", M = 3214 "United States", P = "Los Angeles".</font></li> 3215 <li><font color="#000000">For example, "United States 3216 Time" => N = "United States Time", M = "United 3217 States", P = "".</font></li> 3218 <li><font color="#000000">For example, "United States" 3219 => N = M = "United States", P = "".</font></li> 3220 </ul> 3221 </li> 3222 <li> 3223 <font color="#000000">If P, N, or M is a localized country, 3224 set C to that value. If C has only one zone, return 3225 it.</font> 3226 <ul> 3227 <li><font color="#000000">For example, "Italy Time (xxx)" 3228 or "xxx (Italy)" => Europe/Rome</font></li> 3229 <li><font color="#000000">For example, "xxx (Canada)" or 3230 "Canada Time (xxx)" => Sets C = CA and 3231 continues</font></li> 3232 </ul> 3233 </li> 3234 <li> 3235 <font color="#000000">If P is a localized exemplar city 3236 name (and not metazone), return it.</font> 3237 <ul> 3238 <li><font color="#000000">For example, "xxxx (Phoenix)" 3239 or "Phoenix (xxx)" => America/Phoenix</font></li> 3240 </ul> 3241 </li> 3242 <li> 3243 <font color="#000000">If N, or M is a localized time zone 3244 name (and not metazone), return it.</font> 3245 <ul> 3246 <li><font color="#000000">For example, "Pacific Standard 3247 Time (xxx)" => "America/Los_Angeles" // this is only 3248 if "Pacific Standard Time" is not a metazone 3249 localization.</font></li> 3250 </ul> 3251 </li> 3252 <li> 3253 <font color="#000000">If N or M is a localized 3254 metazone</font> 3255 <ul> 3256 <li><font color="#000000">If it corresponds to only one 3257 TZID, return it.</font></li> 3258 <li><font color="#000000">If C is set, look up the 3259 Metazone + Country => TZID mapping, and return that 3260 value if it exists</font></li> 3261 <li><font color="#000000">Get the locale's language, and 3262 get the default country from that. Look up the Metazone + 3263 DefaultCountry => TZID mapping, and return that value 3264 if it exists.</font></li> 3265 <li><font color="#000000">Otherwise, lookup Metazone + 3266 001 => TZID and return it (that will always 3267 exist)</font></li> 3268 </ul> 3269 </li> 3270 <li><font color="#000000">If you get this far, return an 3271 error.</font></li> 3272 </ol> 3273 <blockquote> 3274 <p><b>Note:</b> This CLDR date parsing recommendation does 3275 not fully handle all RFC 788 date/time formats, nor is it 3276 intended to.</p> 3277 </blockquote> 3278 <p>Parsing can be more lenient than the above, allowing for 3279 different spacing, punctuation, or other variation. A stricter 3280 parse would check for consistency between the xxx portions 3281 above and the rest, so "Pacific Standard Time (India)" would 3282 give an error.</p> 3283 <p>Using this process, a correct parse will roundtrip the 3284 location format (VVVV) back to the canonical zoneid.</p> 3285 <ul> 3286 <li>Australia/ACT → Australia/Sydney → “Sydney (Australia)” → 3287 Australia/Sydney</li> 3288 </ul> 3289 <p>The GMT formats (Z and ZZZZ) will return back an offset, and 3290 thus lose the original canonical zone id.</p> 3291 <ul> 3292 <li>Australia/ACT → Australia/Sydney → "GMT+11:00" → 3293 GMT+11</li> 3294 </ul> 3295 <p>The daylight and standard time formats, and the non-location 3296 formats (z, zzzz, v, and vvvv) may either roundtrip back to the 3297 original canonical zone id, to a zone in the same metazone that 3298 time, or to just an offset, depending on the available 3299 translation data. Thus:</p> 3300 <ul> 3301 <li>Australia/ACT → Australia/Sydney → "GMT+11:00" → 3302 GMT+11</li> 3303 <li>PST8PDT → America/Los_Angeles → “PST” → 3304 America/Los_Angeles</li> 3305 <li>America/Vancouver → “Pacific Time (Canada)” → 3306 America/Vancouver</li> 3307 </ul> 3308 <h2>8 <a name="Date_Format_Patterns" href= 3309 "#Date_Format_Patterns" id="Date_Format_Patterns">Date Format 3310 Patterns</a></h2> 3311 <p>A date pattern is a character string consisting of two types 3312 of elements:</p> 3313 <ul> 3314 <li><em>Pattern fields</em>, which repeat a specific 3315 <em>pattern character</em> one or more times. These fields 3316 are replaced with date and time data from a calendar when 3317 formatting, or used to generate data for a calendar when 3318 parsing. Currently, A..Z and a..z are reserved for use as 3319 pattern characters (unless they are quoted, see next item). 3320 The pattern characters currently defined, and the meaning of 3321 different fields lengths for then, are listed in the Date 3322 Field Symbol Table below.</li> 3323 <li>Literal text, which is output as-is when formatting, and 3324 must closely match when parsing. Literal text can include: 3325 <ul> 3326 <li>Any characters other than A..Z and a..z, including 3327 spaces and punctuation.</li> 3328 <li>Any text between single vertical quotes ('xxxx'), 3329 which may include A..Z and a..z as literal text.</li> 3330 <li>Two adjacent single vertical quotes (''), which 3331 represent a literal single quote, either inside or 3332 outside quoted text.</li> 3333 </ul> 3334 </li> 3335 </ul> 3336 <p>The following are examples:</p> 3337 <table border="1" cellpadding="0" cellspacing="0" style= 3338 "border-style: solid; border-collapse: collapse"> 3339 <caption> 3340 <a name="Date_Format_Pattern_Examples" href= 3341 "#Date_Format_Pattern_Examples" id= 3342 "Date_Format_Pattern_Examples">Date Format Pattern 3343 Examples</a> 3344 </caption> 3345 <tr> 3346 <th width="50%">Pattern</th> 3347 <th width="50%">Result (in a particular locale)</th> 3348 </tr> 3349 <tr> 3350 <td width="50%">yyyy.MM.dd G 'at' HH:mm:ss zzz</td> 3351 <td width="50%">1996.07.10 AD at 15:08:56 PDT</td> 3352 </tr> 3353 <tr> 3354 <td width="50%">EEE, MMM d, ''yy</td> 3355 <td width="50%">Wed, July 10, '96</td> 3356 </tr> 3357 <tr> 3358 <td width="50%">h:mm a</td> 3359 <td width="50%">12:08 PM</td> 3360 </tr> 3361 <tr> 3362 <td width="50%">hh 'o''clock' a, zzzz</td> 3363 <td width="50%">12 o'clock PM, Pacific Daylight Time</td> 3364 </tr> 3365 <tr> 3366 <td width="50%">K:mm a, z</td> 3367 <td width="50%">0:00 PM, PST</td> 3368 </tr> 3369 <tr> 3370 <td width="50%">yyyyy.MMMM.dd GGG hh:mm aaa</td> 3371 <td width="50%">01996.July.10 AD 12:08 PM</td> 3372 </tr> 3373 </table> 3374 <p><i>When parsing using a pattern, a lenient parse should be 3375 used; see <a href="#Parsing_Dates_Times">Parsing Dates and 3376 Times</a>.</i></p> 3377 <p class="dtd"><!ATTLIST pattern numbers CDATA #IMPLIED 3378 ></p> 3379 <p>The numbers attribute is used to indicate that numeric 3380 quantities in the pattern are to be rendered using a numbering 3381 system other than then default numbering system defined for the 3382 given locale. The attribute can be in one of two forms. If the 3383 alternate numbering system is intended to apply to ALL numeric 3384 quantities in the pattern, then simply use the numbering system 3385 ID as found in <a href= 3386 "tr35-numbers.html#Numbering_Systems">Numbering Systems</a>. To 3387 apply the alternate numbering system only to a single field, 3388 the syntax "<letter>=<numberingSystem>" can be used 3389 one or more times, separated by semicolons.</p> 3390 <p class="xmlExample">Examples:<br> 3391 <pattern numbers="hebr">dd/mm/yyyy</pattern><br> 3392 <!-- Use Hebrew numerals to represent numbers in the Hebrew 3393 calendar, where "latn" numbering system is the default 3394 --><br> 3395 <br> 3396 <pattern numbers="y=hebr">dd/mm/yyyy</pattern><br> 3397 <!-- Same as above, except that ONLY the year value would be 3398 rendered in Hebrew --><br> 3399 <br> 3400 <pattern 3401 numbers="d=thai;m=hans;y=deva">dd/mm/yyyy</pattern><br> 3402 3403 <!-- Illustrates use of multiple numbering systems for a 3404 single pattern. --></p><br> 3405 <p><strong>Pattern fields and the Date Field Symbol 3406 Table</strong></p> 3407 <p>The Date Field Symbol Table below shows the pattern 3408 characters (Sym.) and associated fields used in date patterns. 3409 The length of the pattern field is related to the length and 3410 style used to format the data item. For numeric-only fields, 3411 the field length typically indicates the minimum number of 3412 digits that should be used to display the value (zero-padding 3413 as necessary). As an example using pattern character ‘H’ for 3414 hour (24-hour cycle) and values 5 and 11, a field “H” should 3415 produce formatted results “5” and “11” while a field “HH” 3416 should produce formatted results “05” and “11”. For 3417 alphanumeric fields (such as months) and alphabetic-only fields 3418 (such as era names), the relationship between field length and 3419 formatted result may be more complex. Typically this is as 3420 follows:</p> 3421 <table cellspacing="0" cellpadding="2" border="1"> 3422 <tr> 3423 <th>Pattern field<br> 3424 length</th> 3425 <th>Typical style,<br> 3426 alphanumeric item</th> 3427 <th>Typical style,<br> 3428 alpha-only item</th> 3429 </tr> 3430 <tr> 3431 <td>1</td> 3432 <td>Numeric, 1-2 digits (e.g. M)</td> 3433 <td rowspan="3">Abbreviated (e.g. E, EE, EEE)</td> 3434 </tr> 3435 <tr> 3436 <td>2</td> 3437 <td>Numeric, 2 digits (e.g. MM)</td> 3438 </tr> 3439 <tr> 3440 <td>3</td> 3441 <td>Abbreviated (e.g. MMM)</td> 3442 </tr> 3443 <tr> 3444 <td>4</td> 3445 <td colspan="2">Wide / Long / Full (e.g. MMMM, EEEE)</td> 3446 </tr> 3447 <tr> 3448 <td>5</td> 3449 <td colspan="2">Narrow (e.g. MMMMM, EEEEE)<br> 3450 (The counter-intuitive use of 5 letters for this is forced 3451 by backwards compatibility)</td> 3452 </tr> 3453 </table> 3454 <p>Notes for the table below:</p> 3455 <ul> 3456 <li>Any sequence of pattern characters other than those 3457 listed below is invalid. Invalid pattern fields should be 3458 handled for formatting and parsing as described in <a href= 3459 "tr35.html#Invalid_Patterns">Handling Invalid 3460 Patterns</a>.</li> 3461 <li>The examples in the table below are merely illustrative 3462 and may not reflect current actual data.</li> 3463 </ul> 3464 <table cellspacing="0" cellpadding="2" border="1"> 3465 <caption> 3466 <a name="Date_Field_Symbol_Table" href= 3467 "#Date_Field_Symbol_Table" id= 3468 "Date_Field_Symbol_Table">Date Field Symbol Table</a> 3469 </caption> 3470 <tr> 3471 <th>Field<br> 3472 Type</th> 3473 <th style="text-align: center">Sym.</th> 3474 <th style="text-align: center">Field<br> 3475 Patterns</th> 3476 <th>Examples</th> 3477 <th colspan="2">Description</th> 3478 </tr> 3479 <tr> 3480 <th rowspan="3" style= 3481 "vertical-align: top; text-align: left"><a name='dfst-era' 3482 href='#dfst-era' id="dfst-era">era</a></th> 3483 <td style="text-align: center; vertical-align: top" 3484 rowspan="3">G</td> 3485 <td style="text-align: center; vertical-align: top"> 3486 G..GGG</td> 3487 <td style="vertical-align: top; text-align: left">AD<br> 3488 [variant: CE]</td> 3489 <td style="width:130px">Abbreviated</td> 3490 <td rowspan="3" style= 3491 "vertical-align: top; text-align: left">Era name. Era 3492 string for the current date.</td> 3493 </tr> 3494 <tr> 3495 <td style="text-align: center; vertical-align: top"> 3496 GGGG</td> 3497 <td style="vertical-align: top; text-align: left">Anno 3498 Domini<br> 3499 [variant: Common Era]</td> 3500 <td>Wide</td> 3501 </tr> 3502 <tr> 3503 <td style="text-align: center; vertical-align: top"> 3504 GGGGG</td> 3505 <td style="vertical-align: top; text-align: left">A</td> 3506 <td>Narrow</td> 3507 </tr> 3508 <tr> 3509 <th rowspan="15"><a name='dfst-year' href='#dfst-year' id= 3510 "dfst-year">year</a><a name="Year_Length_Examples" id= 3511 "Year_Length_Examples"></a></th> 3512 <td rowspan="5" style="text-align: center">y</td> 3513 <td style="text-align: center">y</td> 3514 <td>2, 20, 201, 2017, 20173</td> 3515 <td rowspan="5" colspan="2">Calendar year (numeric). In 3516 most cases the length of the y field specifies the minimum 3517 number of digits to display, zero-padded as necessary; more 3518 digits will be displayed if needed to show the full year. 3519 However, “yy” requests just the two low-order digits of the 3520 year, zero-padded as necessary. For most use cases, “y” or 3521 “yy” should be adequate.</td> 3522 </tr> 3523 <tr> 3524 <td style="text-align: center">yy</td> 3525 <td>02, 20, 01, 17, 73</td> 3526 </tr> 3527 <tr> 3528 <td style="text-align: center">yyy</td> 3529 <td>002, 020, 201, 2017, 20173</td> 3530 </tr> 3531 <tr> 3532 <td style="text-align: center">yyyy</td> 3533 <td>0002, 0020, 0201, 2017, 20173</td> 3534 </tr> 3535 <tr> 3536 <td style="text-align: center">yyyyy+</td> 3537 <td>...</td> 3538 </tr> 3539 <tr> 3540 <td rowspan="5" style="text-align: center">Y</td> 3541 <td style="text-align: center">Y</td> 3542 <td>2, 20, 201, 2017, 20173</td> 3543 <td rowspan="5" colspan="2">Year in “Week of Year” based 3544 calendars in which the year transition occurs on a week 3545 boundary; may differ from calendar year ‘y’ near a year 3546 transition. This numeric year designation is used in 3547 conjunction with pattern character ‘w’ in the ISO year-week 3548 calendar as defined by ISO 8601, but can be used in 3549 non-Gregorian based calendar systems where week date 3550 processing is desired. The field length is interpreted in 3551 the same was as for ‘y’; that is, “yy” specifies use 3552 of the two low-order year digits, while any other field 3553 length specifies a minimum number of digits to 3554 display.</td> 3555 </tr> 3556 <tr> 3557 <td style="text-align: center">YY</td> 3558 <td>02, 20, 01, 17, 73</td> 3559 </tr> 3560 <tr> 3561 <td style="text-align: center">YYY</td> 3562 <td>002, 020, 201, 2017, 20173</td> 3563 </tr> 3564 <tr> 3565 <td style="text-align: center">YYYY</td> 3566 <td>0002, 0020, 0201, 2017, 20173</td> 3567 </tr> 3568 <tr> 3569 <td style="text-align: center">YYYYY+</td> 3570 <td>...</td> 3571 </tr> 3572 <tr> 3573 <td style="text-align: center">u</td> 3574 <td style="text-align: center">u+</td> 3575 <td>4601</td> 3576 <td colspan="2">Extended year (numeric). This is a single 3577 number designating the year of this calendar system, 3578 encompassing all supra-year fields. For example, for the 3579 Julian calendar system, year numbers are positive, with an 3580 era of BCE or CE. An extended year value for the Julian 3581 calendar system assigns positive values to CE years and 3582 negative values to BCE years, with 1 BCE being year 0. For 3583 ‘u’, all field lengths specify a minimum number of digits; 3584 there is no special interpretation for “uu”.</td> 3585 </tr> 3586 <tr> 3587 <td style="text-align: center; vertical-align: top" 3588 rowspan="3">U</td> 3589 <td style="text-align: center; vertical-align: top"> 3590 U..UUU</td> 3591 <td style="vertical-align: top; text-align: left">甲子</td> 3592 <td>Abbreviated</td> 3593 <td rowspan="3" style= 3594 "vertical-align: top; text-align: left">Cyclic year name. 3595 Calendars such as the Chinese lunar calendar (and related 3596 calendars) and the Hindu calendars use 60-year cycles of 3597 year names. If the calendar does not provide cyclic year 3598 name data, or if the year value to be formatted is out of 3599 the range of years for which cyclic name data is provided, 3600 then numeric formatting is used (behaves like 'y').<br> 3601 Currently the data only provides abbreviated names, which 3602 will be used for all requested name widths.</td> 3603 </tr> 3604 <tr> 3605 <td style="text-align: center; vertical-align: top"> 3606 UUUU</td> 3607 <td style="vertical-align: top; text-align: left">甲子 [for 3608 now]</td> 3609 <td>Wide</td> 3610 </tr> 3611 <tr> 3612 <td style="text-align: center; vertical-align: top"> 3613 UUUUU</td> 3614 <td style="vertical-align: top; text-align: left">甲子 [for 3615 now]</td> 3616 <td>Narrow</td> 3617 </tr> 3618 <tr> 3619 <td>r</td> 3620 <td style="text-align: center; vertical-align: top">r+</td> 3621 <td>2017</td> 3622 <td colspan="2">Related Gregorian year (numeric). For 3623 non-Gregorian calendars, this corresponds to the extended 3624 Gregorian year in which the calendar’s year begins. Related 3625 Gregorian years are often displayed, for example, when 3626 formatting dates in the Japanese calendar — e.g. 3627 “2012(平成24)年1月15日” — or in the Chinese calendar — e.g. 3628 “2012壬辰年腊月初四”. The related Gregorian year is usually 3629 displayed using the "latn" numbering system, regardless of 3630 what numbering systems may be used for other parts of the 3631 formatted date. If the calendar’s year is linked to the 3632 solar year (perhaps using leap months), then for that 3633 calendar the ‘r’ year will always be at a fixed offset from 3634 the ‘u’ year. For the Gregorian calendar, the ‘r’ year is 3635 the same as the ‘u’ year. For ‘r’, all field lengths 3636 specify a minimum number of digits; there is no special 3637 interpretation for “rr”.</td> 3638 </tr> 3639 <tr> 3640 <th rowspan="10" style= 3641 "vertical-align: top; text-align: left"><a name= 3642 'dfst-quarter' href='#dfst-quarter' id= 3643 "dfst-quarter">quarter</a></th> 3644 <td style="text-align: center; vertical-align: top" 3645 rowspan="5">Q</td> 3646 <td style="text-align: center; vertical-align: top">Q</td> 3647 <td style="vertical-align: top; text-align: left">2</td> 3648 <td>Numeric: 1 digit</td> 3649 <td rowspan="5">Quarter number/name.</td> 3650 </tr> 3651 <tr> 3652 <td style="text-align: center; vertical-align: top">QQ</td> 3653 <td style="vertical-align: top; text-align: left">02</td> 3654 <td>Numeric: 2 digits + zero pad</td> 3655 </tr> 3656 <tr> 3657 <td style="text-align: center; vertical-align: top"> 3658 QQQ</td> 3659 <td style="vertical-align: top; text-align: left">Q2</td> 3660 <td>Abbreviated</td> 3661 </tr> 3662 <tr> 3663 <td style="text-align: center; vertical-align: top"> 3664 QQQQ</td> 3665 <td style="vertical-align: top; text-align: left">2nd 3666 quarter</td> 3667 <td>Wide</td> 3668 </tr> 3669 <tr> 3670 <td style="text-align: center; vertical-align: top"> 3671 QQQQQ</td> 3672 <td style="vertical-align: top; text-align: left">2</td> 3673 <td>Narrow</td> 3674 </tr> 3675 <tr> 3676 <td style="text-align: center; vertical-align: top" 3677 rowspan="5">q</td> 3678 <td style="text-align: center; vertical-align: top">q</td> 3679 <td style="vertical-align: top; text-align: left">2</td> 3680 <td>Numeric: 1 digit</td> 3681 <td rowspan="5" style= 3682 "vertical-align: top; text-align: left"><b>Stand-Alone</b> 3683 Quarter number/name.</td> 3684 </tr> 3685 <tr> 3686 <td style="text-align: center; vertical-align: top">qq</td> 3687 <td style="vertical-align: top; text-align: left">02</td> 3688 <td>Numeric: 2 digits + zero pad</td> 3689 </tr> 3690 <tr> 3691 <td style="text-align: center; vertical-align: top"> 3692 qqq</td> 3693 <td style="vertical-align: top; text-align: left">Q2</td> 3694 <td>Abbreviated</td> 3695 </tr> 3696 <tr> 3697 <td style="text-align: center; vertical-align: top"> 3698 qqqq</td> 3699 <td style="vertical-align: top; text-align: left">2nd 3700 quarter</td> 3701 <td>Wide</td> 3702 </tr> 3703 <tr> 3704 <td style="text-align: center; vertical-align: top"> 3705 qqqqq</td> 3706 <td style="vertical-align: top; text-align: left">2</td> 3707 <td>Narrow</td> 3708 </tr> 3709 <tr> 3710 <th rowspan="11" style= 3711 "vertical-align: top; text-align: left"><a name= 3712 'dfst-month' href='#dfst-month' id= 3713 "dfst-month">month</a></th> 3714 <td rowspan="5" style= 3715 "text-align: center; vertical-align: top">M</td> 3716 <td style="text-align: center; vertical-align: top">M</td> 3717 <td>9, 12</td> 3718 <td>Numeric: minimum digits</td> 3719 <td rowspan="5" style= 3720 "vertical-align: top; text-align: left">Month number/name, 3721 format style (intended to be used in conjunction with ‘d’ 3722 for day number).</td> 3723 </tr> 3724 <tr> 3725 <td style="text-align: center; vertical-align: top">MM</td> 3726 <td>09, 12</td> 3727 <td>Numeric: 2 digits, zero pad if needed</td> 3728 </tr> 3729 <tr> 3730 <td style="text-align: center; vertical-align: top"> 3731 MMM</td> 3732 <td style="vertical-align: top; text-align: left">Sep</td> 3733 <td>Abbreviated</td> 3734 </tr> 3735 <tr> 3736 <td style="text-align: center; vertical-align: top"> 3737 MMMM</td> 3738 <td style="vertical-align: top; text-align: left"> 3739 September</td> 3740 <td>Wide</td> 3741 </tr> 3742 <tr> 3743 <td style="text-align: center; vertical-align: top"> 3744 MMMMM</td> 3745 <td style="vertical-align: top; text-align: left">S</td> 3746 <td>Narrow</td> 3747 </tr> 3748 <tr> 3749 <td rowspan="5" style= 3750 "text-align: center; vertical-align: top">L</td> 3751 <td style="text-align: center; vertical-align: top">L</td> 3752 <td>9, 12</td> 3753 <td>Numeric: minimum digits</td> 3754 <td rowspan="5"><b>Stand-Alone</b> Month number/name 3755 (intended to be used without ‘d’ for day number).</td> 3756 </tr> 3757 <tr> 3758 <td style="text-align: center; vertical-align: top">LL</td> 3759 <td>09, 12</td> 3760 <td>Numeric: 2 digits, zero pad if needed</td> 3761 </tr> 3762 <tr> 3763 <td style="text-align: center; vertical-align: top"> 3764 LLL</td> 3765 <td style="vertical-align: top; text-align: left">Sep</td> 3766 <td>Abbreviated</td> 3767 </tr> 3768 <tr> 3769 <td style="text-align: center; vertical-align: top"> 3770 LLLL</td> 3771 <td style="vertical-align: top; text-align: left"> 3772 September</td> 3773 <td>Wide</td> 3774 </tr> 3775 <tr> 3776 <td style="text-align: center; vertical-align: top"> 3777 LLLLL</td> 3778 <td style="vertical-align: top; text-align: left">S</td> 3779 <td>Narrow</td> 3780 </tr> 3781 <tr> 3782 <td style="text-align: center">l</td> 3783 <td style="text-align: center">l</td> 3784 <td>[nothing]</td> 3785 <td colspan="2">This pattern character is deprecated, and 3786 should be ignored in patterns. It was originally intended 3787 to be used in combination with M to indicate placement of 3788 the symbol for leap month in the Chinese calendar. 3789 Placement of that marker is now specified using 3790 locale-specific <monthPatterns> data, and formatting 3791 and parsing of that marker should be handled as part of 3792 supporting the regular M and L pattern characters.</td> 3793 </tr> 3794 <tr> 3795 <th rowspan="3"><a name='dfst-week' href='#dfst-week' id= 3796 "dfst-week">week</a></th> 3797 <td rowspan="2" style="text-align: center">w</td> 3798 <td style="text-align: center">w</td> 3799 <td>8, 27</td> 3800 <td>Numeric: minimum digits</td> 3801 <td rowspan="2">Week of Year (numeric). When used in a 3802 pattern with year, use ‘Y’ for the year field instead of 3803 ‘y’.</td> 3804 </tr> 3805 <tr> 3806 <td style="text-align: center; vertical-align: top">ww</td> 3807 <td>08, 27</td> 3808 <td>Numeric: 2 digits, zero pad if needed</td> 3809 </tr> 3810 <tr> 3811 <td style="text-align: center">W</td> 3812 <td style="text-align: center">W</td> 3813 <td>3</td> 3814 <td>Numeric: 1 digit</td> 3815 <td>Week of Month (numeric)</td> 3816 </tr> 3817 <tr> 3818 <th rowspan="5"><a name='dfst-day' href='#dfst-day' id= 3819 "dfst-day">day</a></th> 3820 <td rowspan="2" style="text-align: center">d</td> 3821 <td style="text-align: center">d</td> 3822 <td>1</td> 3823 <td>Numeric: minimum digits</td> 3824 <td rowspan="2">Day of month (numeric).</td> 3825 </tr> 3826 <tr> 3827 <td style="text-align: center">dd</td> 3828 <td>01</td> 3829 <td>Numeric: 2 digits, zero pad if needed</td> 3830 </tr> 3831 <tr> 3832 <td style="text-align: center">D</td> 3833 <td style="text-align: center">D...DDD</td> 3834 <td>345</td> 3835 <td colspan="2">Day of year (numeric). The field length 3836 specifies the minimum number of digits, with zero-padding 3837 as necessary.</td> 3838 </tr> 3839 <tr> 3840 <td style="text-align: center">F</td> 3841 <td style="text-align: center">F</td> 3842 <td>2</td> 3843 <td colspan="2">Day of Week in Month (numeric). The example 3844 is for the 2nd Wed in July</td> 3845 </tr> 3846 <tr> 3847 <td style="text-align: center">g</td> 3848 <td style="text-align: center">g+</td> 3849 <td>2451334</td> 3850 <td colspan="2">Modified Julian day (numeric). This is 3851 different from the conventional Julian day number in two 3852 regards. First, it demarcates days at local zone midnight, 3853 rather than noon GMT. Second, it is a local number; that 3854 is, it depends on the local time zone. It can be thought of 3855 as a single number that encompasses all the date-related 3856 fields.The field length specifies the minimum number of 3857 digits, with zero-padding as necessary.</td> 3858 </tr> 3859 <tr> 3860 <th rowspan="15" style= 3861 "vertical-align: top; text-align: left"><a name= 3862 'dfst-weekday' href='#dfst-weekday' id= 3863 "dfst-weekday">week<br> 3864 day</a></th> 3865 <td rowspan="4" style= 3866 "text-align: center; vertical-align: top">E</td> 3867 <td style="text-align: center; vertical-align: top"> 3868 E..EEE</td> 3869 <td style="vertical-align: top; text-align: left">Tue</td> 3870 <td>Abbreviated</td> 3871 <td rowspan="4">Day of week name, format style.</td> 3872 </tr> 3873 <tr> 3874 <td style="text-align: center; vertical-align: top"> 3875 EEEE</td> 3876 <td style="vertical-align: top; text-align: left"> 3877 Tuesday</td> 3878 <td>Wide</td> 3879 </tr> 3880 <tr> 3881 <td style="text-align: center; vertical-align: top"> 3882 EEEEE</td> 3883 <td style="vertical-align: top; text-align: left">T</td> 3884 <td>Narrow</td> 3885 </tr> 3886 <tr> 3887 <td style="text-align: center; vertical-align: top"> 3888 EEEEEE</td> 3889 <td style="vertical-align: top; text-align: left">Tu</td> 3890 <td>Short</td> 3891 </tr> 3892 <tr> 3893 <td rowspan="6" style= 3894 "text-align: center; vertical-align: top">e</td> 3895 <td style="text-align: center; vertical-align: top">e</td> 3896 <td style="vertical-align: top; text-align: left">2</td> 3897 <td>Numeric: 1 digit</td> 3898 <td rowspan="6" style= 3899 "vertical-align: top; text-align: left">Local day of week 3900 number/name, format style. Same as E except adds a numeric 3901 value that will depend on the local starting day of the 3902 week. For this example, Monday is the first day of the 3903 week.</td> 3904 </tr> 3905 <tr> 3906 <td style="text-align: center; vertical-align: top">ee</td> 3907 <td>02</td> 3908 <td>Numeric: 2 digits + zero pad</td> 3909 </tr> 3910 <tr> 3911 <td style="text-align: center; vertical-align: top"> 3912 eee</td> 3913 <td style="vertical-align: top; text-align: left">Tue</td> 3914 <td>Abbreviated</td> 3915 </tr> 3916 <tr> 3917 <td style="text-align: center; vertical-align: top"> 3918 eeee</td> 3919 <td style="vertical-align: top; text-align: left"> 3920 Tuesday</td> 3921 <td>Wide</td> 3922 </tr> 3923 <tr> 3924 <td style="text-align: center; vertical-align: top"> 3925 eeeee</td> 3926 <td style="vertical-align: top; text-align: left">T</td> 3927 <td>Narrow</td> 3928 </tr> 3929 <tr> 3930 <td style="text-align: center; vertical-align: top"> 3931 eeeeee</td> 3932 <td style="vertical-align: top; text-align: left">Tu</td> 3933 <td>Short</td> 3934 </tr> 3935 <tr> 3936 <td rowspan="5" style= 3937 "text-align: center; vertical-align: top">c</td> 3938 <td style="text-align: center; vertical-align: top"> 3939 c..cc</td> 3940 <td style="vertical-align: top; text-align: left">2</td> 3941 <td>Numeric: 1 digit</td> 3942 <td rowspan="5"><b>Stand-Alone</b> local day of week 3943 number/name.</td> 3944 </tr> 3945 <tr> 3946 <td style="text-align: center; vertical-align: top"> 3947 ccc</td> 3948 <td style="vertical-align: top; text-align: left">Tue</td> 3949 <td>Abbreviated</td> 3950 </tr> 3951 <tr> 3952 <td style="text-align: center; vertical-align: top"> 3953 cccc</td> 3954 <td style="vertical-align: top; text-align: left"> 3955 Tuesday</td> 3956 <td>Wide</td> 3957 </tr> 3958 <tr> 3959 <td style="text-align: center; vertical-align: top"> 3960 ccccc</td> 3961 <td style="vertical-align: top; text-align: left">T</td> 3962 <td>Narrow</td> 3963 </tr> 3964 <tr> 3965 <td style="text-align: center; vertical-align: top"> 3966 cccccc</td> 3967 <td style="vertical-align: top; text-align: left">Tu</td> 3968 <td>Short</td> 3969 </tr> 3970 <tr> 3971 <th rowspan="9"><a name='dfst-period' href='#dfst-period' 3972 id="dfst-period">period</a></th> 3973 <td rowspan="3" style="text-align: center">a</td> 3974 <td style="text-align: center">a..aaa</td> 3975 <td>am. [e.g. 12 am.]</td> 3976 <td>Abbreviated</td> 3977 <td rowspan="3"><strong>AM, PM<br></strong> May be upper or 3978 lowercase depending on the locale and other options. The 3979 wide form may be the same as the short form if the “real” 3980 long form (eg <em>ante meridiem</em>) is not customarily 3981 used. The narrow form must be unique, unlike some other 3982 fields. See also Section 9 <a href= 3983 "#Parsing_Dates_Times">Parsing Dates and Times</a>.</td> 3984 </tr> 3985 <tr> 3986 <td style="text-align: center">aaaa</td> 3987 <td>am. [e.g. 12 am.]</td> 3988 <td>Wide</td> 3989 </tr> 3990 <tr> 3991 <td style="text-align: center">aaaaa</td> 3992 <td>a [e.g. 12a]</td> 3993 <td>Narrow</td> 3994 </tr> 3995 <tr> 3996 <td rowspan="3" style="text-align: center">b</td> 3997 <td style="text-align: center">b..bbb</td> 3998 <td>mid. [e.g. 12 mid.]</td> 3999 <td>Abbreviated</td> 4000 <td rowspan="3"><strong>am, pm, noon, midnight</strong><br> 4001 May be upper or lowercase depending on the locale and other 4002 options. If the locale doesn't the notion of a unique 4003 "noon" = 12:00, then the PM form may be substituted. 4004 Similarly for "midnight" = 00:00 and the AM form. The 4005 narrow form must be unique, unlike some other fields.</td> 4006 </tr> 4007 <tr> 4008 <td style="text-align: center">bbbb</td> 4009 <td>midnight<br> 4010 [e.g. 12 midnight]</td> 4011 <td>Wide</td> 4012 </tr> 4013 <tr> 4014 <td style="text-align: center">bbbbb</td> 4015 <td>md [e.g. 12 md]</td> 4016 <td>Narrow</td> 4017 </tr> 4018 <tr> 4019 <td rowspan="3" style="text-align: center">B</td> 4020 <td style="text-align: center">B..BBB</td> 4021 <td>at night<br> 4022 [e.g. 3:00 at night]</td> 4023 <td>Abbreviated</td> 4024 <td rowspan="3"><strong>flexible day periods</strong><br> 4025 May be upper or lowercase depending on the locale and other 4026 options. Often there is only one width that is customarily 4027 used.</td> 4028 </tr> 4029 <tr> 4030 <td style="text-align: center">BBBB</td> 4031 <td>at night<br> 4032 [e.g. 3:00 at night]</td> 4033 <td>Wide</td> 4034 </tr> 4035 <tr> 4036 <td style="text-align: center">BBBBB</td> 4037 <td>at night<br> 4038 [e.g. 3:00 at night]</td> 4039 <td>Narrow</td> 4040 </tr> 4041 <tr> 4042 <th rowspan="22"><a name='dfst-hour' href='#dfst-hour' id= 4043 "dfst-hour">hour</a></th> 4044 <td rowspan="2" style="text-align: center">h</td> 4045 <td style="text-align: center">h</td> 4046 <td>1, 12</td> 4047 <td>Numeric: minimum digits</td> 4048 <td rowspan="2">Hour [1-12]. When used in skeleton data or 4049 in a skeleton passed in an API for flexible date pattern 4050 generation, it should match the 12-hour-cycle format 4051 preferred by the locale (h or K); it should not match a 4052 24-hour-cycle format (H or k).</td> 4053 </tr> 4054 <tr> 4055 <td style="text-align: center">hh</td> 4056 <td>01, 12</td> 4057 <td>Numeric: 2 digits, zero pad if needed</td> 4058 </tr> 4059 <tr> 4060 <td rowspan="2" style="text-align: center">H</td> 4061 <td style="text-align: center">H</td> 4062 <td>0, 23</td> 4063 <td>Numeric: minimum digits</td> 4064 <td rowspan="2">Hour [0-23]. When used in skeleton data or 4065 in a skeleton passed in an API for flexible date pattern 4066 generation, it should match the 24-hour-cycle format 4067 preferred by the locale (H or k); it should not match a 4068 12-hour-cycle format (h or K).</td> 4069 </tr> 4070 <tr> 4071 <td style="text-align: center">HH</td> 4072 <td>00, 23</td> 4073 <td>Numeric: 2 digits, zero pad if needed</td> 4074 </tr> 4075 <tr> 4076 <td rowspan="2" style="text-align: center">K</td> 4077 <td style="text-align: center">K</td> 4078 <td>0, 11</td> 4079 <td>Numeric: minimum digits</td> 4080 <td rowspan="2">Hour [0-11]. When used in a skeleton, only 4081 matches K or h, see above.</td> 4082 </tr> 4083 <tr> 4084 <td style="text-align: center">KK</td> 4085 <td>00, 11</td> 4086 <td>Numeric: 2 digits, zero pad if needed</td> 4087 </tr> 4088 <tr> 4089 <td rowspan="2" style="text-align: center">k</td> 4090 <td style="text-align: center">k</td> 4091 <td>1, 24</td> 4092 <td>Numeric: minimum digits</td> 4093 <td rowspan="2">Hour [1-24]. When used in a skeleton, only 4094 matches k or H, see above.</td> 4095 </tr> 4096 <tr> 4097 <td style="text-align: center">kk</td> 4098 <td>01, 24</td> 4099 <td>Numeric: 2 digits, zero pad if needed</td> 4100 </tr> 4101 <tr> 4102 <td rowspan="6" style="text-align: center">j</td> 4103 <td>j</td> 4104 <td>8<br> 4105 8 AM<br> 4106 13<br> 4107 1 PM</td> 4108 <td>Numeric hour (minimum digits), abbreviated dayPeriod if 4109 used</td> 4110 <td rowspan="6"><em><strong>Input skeleton 4111 symbol</strong></em><br> 4112 It must not occur in pattern or skeleton data. Instead, it 4113 is reserved for use in skeletons passed to APIs doing 4114 flexible date pattern generation. In such a context, it 4115 requests the preferred hour format for the locale (h, H, K, 4116 or k), as determined by the <strong>preferred</strong> 4117 attribute of the <strong>hours</strong> element in 4118 supplemental data . In the implementation of such an API, 4119 'j' must be replaced by h, H, K, or k before beginning a 4120 match against availableFormats data.<br> 4121 Note that use of 'j' in a skeleton passed to an API is the 4122 only way to have a skeleton request a locale's preferred 4123 time cycle type (12-hour or 24-hour).</td> 4124 </tr> 4125 <tr> 4126 <td style="text-align: center">jj</td> 4127 <td>08<br> 4128 08 AM<br> 4129 13<br> 4130 01 PM</td> 4131 <td>Numeric hour (2 digits, zero pad if needed), 4132 abbreviated dayPeriod if used</td> 4133 </tr> 4134 <tr> 4135 <td style="text-align: center">jjj</td> 4136 <td>8<br> 4137 8 A.M.<br> 4138 13<br> 4139 1 P.M.</td> 4140 <td>Numeric hour (minimum digits), wide dayPeriod if 4141 used</td> 4142 </tr> 4143 <tr> 4144 <td style="text-align: center">jjjj</td> 4145 <td>08<br> 4146 08 A.M.<br> 4147 13<br> 4148 01 P.M.</td> 4149 <td>Numeric hour (2 digits, zero pad if needed), wide 4150 dayPeriod if used</td> 4151 </tr> 4152 <tr> 4153 <td style="text-align: center">jjjjj</td> 4154 <td>8<br> 4155 8a<br> 4156 13<br> 4157 1p</td> 4158 <td>Numeric hour (minimum digits), narrow dayPeriod if 4159 used</td> 4160 </tr> 4161 <tr> 4162 <td style="text-align: center">jjjjjj</td> 4163 <td>08<br> 4164 08a<br> 4165 13<br> 4166 01p</td> 4167 <td>Numeric hour (2 digits, zero pad if needed), narrow 4168 dayPeriod if used</td> 4169 </tr> 4170 <tr> 4171 <td rowspan="2" style="text-align: center">J</td> 4172 <td style="text-align: center">J</td> 4173 <td>8<br> 4174 8</td> 4175 <td>Numeric hour (minimum digits)</td> 4176 <td rowspan="2"><em><strong>Input skeleton 4177 symbol</strong></em><br> 4178 It must not occur in pattern or skeleton data. Instead, it 4179 is reserved for use in skeletons passed to APIs doing 4180 flexible date pattern generation. In such a context, like 4181 'j', it requests the preferred hour format for the locale 4182 (h, H, K, or k), as determined by the 4183 <strong>preferred</strong> attribute of the 4184 <strong>hours</strong> element in supplemental data. 4185 However, unlike 'j', it requests no dayPeriod marker such 4186 as “am/pm” (It is typically used where there is enough 4187 context that that is not necessary). For example, with 4188 "jmm", 18:00 could appear as “6:00 PM”, while with "Jmm", 4189 it would appear as “6:00” (no PM).</td> 4190 </tr> 4191 <tr> 4192 <td style="text-align: center">JJ</td> 4193 <td>08<br> 4194 08</td> 4195 <td>Numeric hour (2 digits, zero pad if needed)</td> 4196 </tr> 4197 <tr> 4198 <td rowspan="6" style="text-align: center">C</td> 4199 <td style="text-align: center">C</td> 4200 <td>8<br> 4201 8 (morning)</td> 4202 <td>Numeric hour (minimum digits), abbreviated dayPeriod if 4203 used</td> 4204 <td rowspan="6"><em><strong>Input skeleton 4205 symbol</strong></em><br> 4206 It must not occur in pattern or skeleton data. Instead, it 4207 is reserved for use in skeletons passed to APIs doing 4208 flexible date pattern generation. In such a context, like 4209 'j', it requests the preferred hour format for the locale. 4210 However, unlike 'j', it can also select formats such as hb 4211 or hB, since it is based not on the 4212 <strong>preferred</strong> attribute of the 4213 <strong>hours</strong> element in supplemental data, but 4214 instead on the first element of the 4215 <strong>allowed</strong> attribute (which is an ordered 4216 preferrence list. For example, with "Cmm", 18:00 could 4217 appear as “6:00 in the afternoon”.</td> 4218 </tr> 4219 <tr> 4220 <td style="text-align: center">CC</td> 4221 <td>08<br> 4222 08 (morning)</td> 4223 <td>Numeric hour (2 digits, zero pad if needed), 4224 abbreviated dayPeriod if used</td> 4225 </tr> 4226 <tr> 4227 <td style="text-align: center">CCC</td> 4228 <td>8<br> 4229 8 in the morning</td> 4230 <td>Numeric hour (minimum digits), wide dayPeriod if 4231 used</td> 4232 </tr> 4233 <tr> 4234 <td style="text-align: center">CCCC</td> 4235 <td>08<br> 4236 08 in the morning</td> 4237 <td>Numeric hour (2 digits, zero pad if needed), wide 4238 dayPeriod if used</td> 4239 </tr> 4240 <tr> 4241 <td style="text-align: center">CCCCC</td> 4242 <td>8<br> 4243 8 (morn.)</td> 4244 <td>Numeric hour (minimum digits), narrow dayPeriod if 4245 used</td> 4246 </tr> 4247 <tr> 4248 <td style="text-align: center">CCCCCC</td> 4249 <td>08<br> 4250 08 (morn.)</td> 4251 <td>Numeric hour (2 digits, zero pad if needed), narrow 4252 dayPeriod if used</td> 4253 </tr> 4254 <tr> 4255 <th rowspan="2"><a name='dfst-minute' href='#dfst-minute' 4256 id="dfst-minute">minute</a></th> 4257 <td rowspan="2" style="text-align: center">m</td> 4258 <td style="text-align: center">m</td> 4259 <td>8, 59</td> 4260 <td>Numeric: minimum digits</td> 4261 <td rowspan="2">Minute (numeric). Truncated, not 4262 rounded.<br></td> 4263 </tr> 4264 <tr> 4265 <td style="text-align: center">mm</td> 4266 <td>08, 59</td> 4267 <td>Numeric: 2 digits, zero pad if needed</td> 4268 </tr> 4269 <tr> 4270 <th rowspan="4"><a name='dfst-second' href='#dfst-second' 4271 id="dfst-second">second</a></th> 4272 <td rowspan="2" style="text-align: center">s</td> 4273 <td style="text-align: center">s</td> 4274 <td>8, 12</td> 4275 <td>Numeric: minimum digits</td> 4276 <td rowspan="2">Second (numeric). Truncated, not 4277 rounded.<br></td> 4278 </tr> 4279 <tr> 4280 <td style="text-align: center">ss</td> 4281 <td>08, 12</td> 4282 <td>Numeric: 2 digits, zero pad if needed</td> 4283 </tr> 4284 <tr> 4285 <td style="text-align: center">S</td> 4286 <td style="text-align: center">S+</td> 4287 <td>3456</td> 4288 <td colspan="2">Fractional Second (numeric). Truncates, 4289 like other numeric time fields, but in this case to the 4290 number of digits specified by the field length. (Example 4291 shows display using pattern SSSS for seconds value 4292 12.34567)</td> 4293 </tr> 4294 <tr> 4295 <td style="text-align: center">A</td> 4296 <td style="text-align: center">A+</td> 4297 <td>69540000</td> 4298 <td colspan="2">Milliseconds in day (numeric). This field 4299 behaves <i>exactly</i> like a composite of all time-related 4300 fields, not including the zone fields. As such, it also 4301 reflects discontinuities of those fields on DST transition 4302 days. On a day of DST onset, it will jump forward. On a day 4303 of DST cessation, it will jump backward. This reflects the 4304 fact that is must be combined with the offset field to 4305 obtain a unique local time value. The field length 4306 specifies the minimum number of digits, with zero-padding 4307 as necessary.</td> 4308 </tr> 4309 <tr> 4310 <th><a name='dfst-sep' href='#dfst-sep' id= 4311 "dfst-sep">sep.</a></th> 4312 <td>(none def., see note)</td> 4313 <td style="text-align: center"></td> 4314 <td></td> 4315 <td colspan="2">Time separator.<br> 4316 <span class="note"><b><br> 4317 Note:</b> In CLDR 26 the time separator pattern character 4318 was specified to be COLON. This was withdrawn in CLDR 28 4319 due to backward compatibility issues, and no time separator 4320 pattern character is currently defined.</span><br> 4321 <br> 4322 Like the use of "," in number formats, this character in a 4323 date pattern is replaced with the corresponding number 4324 symbol which may depend on the numbering system. For more 4325 information, see <em><strong>Part 3: <a href= 4326 "tr35-numbers.html#Contents">Numbers</a></strong> , Section 4327 2.3 <a href="tr35-numbers.html#Number_Symbols">Number 4328 Symbols</a></em>.</td> 4329 </tr> 4330 <tr> 4331 <th rowspan="23"><a name='dfst-zone' href='#dfst-zone' id= 4332 "dfst-zone">zone</a></th> 4333 <td rowspan="2" style="text-align: center">z</td> 4334 <td style="text-align: center">z..zzz</td> 4335 <td>PDT</td> 4336 <td colspan="2">The <i>short specific non-location 4337 format</i>. Where that is unavailable, falls back to the 4338 <i>short localized GMT format</i> ("O").</td> 4339 </tr> 4340 <tr> 4341 <td style="text-align: center">zzzz</td> 4342 <td>Pacific Daylight Time</td> 4343 <td colspan="2">The <i>long specific non-location 4344 format</i>. Where that is unavailable, falls back to the 4345 <i>long localized GMT format</i> ("OOOO").</td> 4346 </tr> 4347 <tr> 4348 <td rowspan="3" style="text-align: center">Z</td> 4349 <td style="text-align: center">Z..ZZZ</td> 4350 <td>-0800</td> 4351 <td colspan="2">The <i>ISO8601 basic format</i> with hours, 4352 minutes and optional seconds fields. The format is 4353 equivalent to RFC 822 zone format (when optional seconds 4354 field is absent). This is equivalent to the "xxxx" 4355 specifier.</td> 4356 </tr> 4357 <tr> 4358 <td style="text-align: center">ZZZZ</td> 4359 <td>GMT-8:00</td> 4360 <td colspan="2">The <i>long localized GMT format</i>. This 4361 is equivalent to the "OOOO" specifier.</td> 4362 </tr> 4363 <tr> 4364 <td style="text-align: center">ZZZZZ</td> 4365 <td>-08:00<br> 4366 -07:52:58</td> 4367 <td colspan="2">The <i>ISO8601 extended format</i> with 4368 hours, minutes and optional seconds fields. The ISO8601 UTC 4369 indicator "Z" is used when local time offset is 0. This is 4370 equivalent to the "XXXXX" specifier.</td> 4371 </tr> 4372 <tr> 4373 <td rowspan="2" style="text-align: center">O</td> 4374 <td style="text-align: center">O</td> 4375 <td>GMT-8</td> 4376 <td colspan="2">The <i>short localized GMT format</i>.</td> 4377 </tr> 4378 <tr> 4379 <td style="text-align: center">OOOO</td> 4380 <td>GMT-08:00</td> 4381 <td colspan="2">The <i>long localized GMT format</i>.</td> 4382 </tr> 4383 <tr> 4384 <td rowspan="2" style="text-align: center">v</td> 4385 <td style="text-align: center">v</td> 4386 <td>PT</td> 4387 <td colspan="2">The <i>short generic non-location 4388 format</i>. Where that is unavailable, falls back to the 4389 <i>generic location format</i> ("VVVV"), then the <i>short 4390 localized GMT format</i> as the final fallback.</td> 4391 </tr> 4392 <tr> 4393 <td style="text-align: center">vvvv</td> 4394 <td>Pacific Time</td> 4395 <td colspan="2">The <i>long generic non-location 4396 format</i>. Where that is unavailable, falls back to 4397 <i>generic location format</i> ("VVVV").</td> 4398 </tr> 4399 <tr> 4400 <td rowspan="4" style="text-align: center">V</td> 4401 <td style="text-align: center">V</td> 4402 <td>uslax</td> 4403 <td colspan="2">The short time zone ID. Where that is 4404 unavailable, the special short time zone ID <i>unk</i> 4405 (Unknown Zone) is used.<br> 4406 <i><b>Note</b>: This specifier was originally used for a 4407 variant of the short specific non-location format, but it 4408 was deprecated in the later version of this specification. 4409 In CLDR 23, the definition of the specifier was changed to 4410 designate a short time zone ID.</i></td> 4411 </tr> 4412 <tr> 4413 <td style="text-align: center">VV</td> 4414 <td>America/Los_Angeles</td> 4415 <td colspan="2">The long time zone ID.</td> 4416 </tr> 4417 <tr> 4418 <td style="text-align: center">VVV</td> 4419 <td>Los Angeles</td> 4420 <td colspan="2">The exemplar city (location) for the time 4421 zone. Where that is unavailable, the localized exemplar 4422 city name for the special zone <i>Etc/Unknown</i> is used 4423 as the fallback (for example, "Unknown City").</td> 4424 </tr> 4425 <tr> 4426 <td style="text-align: center">VVVV</td> 4427 <td>Los Angeles Time</td> 4428 <td colspan="2">The <i>generic location format</i>. Where 4429 that is unavailable, falls back to the <i>long localized 4430 GMT format</i> ("OOOO"; Note: Fallback is only necessary 4431 with a GMT-style Time Zone ID, like Etc/GMT-830.)<br> 4432 This is especially useful when presenting possible timezone 4433 choices for user selection, since the naming is more 4434 uniform than the "v" format.</td> 4435 </tr> 4436 <tr> 4437 <td rowspan="5" style="text-align: center">X</td> 4438 <td style="text-align: center">X</td> 4439 <td>-08<br> 4440 +0530<br> 4441 Z</td> 4442 <td colspan="2">The <i>ISO8601 basic format</i> with hours 4443 field and optional minutes field. The ISO8601 UTC indicator 4444 "Z" is used when local time offset is 0. (The same as x, 4445 plus "Z".)</td> 4446 </tr> 4447 <tr> 4448 <td style="text-align: center">XX</td> 4449 <td>-0800<br> 4450 Z</td> 4451 <td colspan="2">The <i>ISO8601 basic format</i> with hours 4452 and minutes fields. The ISO8601 UTC indicator "Z" is used 4453 when local time offset is 0. (The same as xx, plus 4454 "Z".)</td> 4455 </tr> 4456 <tr> 4457 <td style="text-align: center">XXX</td> 4458 <td>-08:00<br> 4459 Z</td> 4460 <td colspan="2">The <i>ISO8601 extended format</i> with 4461 hours and minutes fields. The ISO8601 UTC indicator "Z" is 4462 used when local time offset is 0. (The same as xxx, plus 4463 "Z".)</td> 4464 </tr> 4465 <tr> 4466 <td style="text-align: center">XXXX</td> 4467 <td>-0800<br> 4468 -075258<br> 4469 Z</td> 4470 <td colspan="2">The <i>ISO8601 basic format</i> with hours, 4471 minutes and optional seconds fields. The ISO8601 UTC 4472 indicator "Z" is used when local time offset is 0. (The 4473 same as xxxx, plus "Z".)<br> 4474 <i><b>Note</b>: The seconds field is not supported by the 4475 ISO8601 specification.</i></td> 4476 </tr> 4477 <tr> 4478 <td style="text-align: center">XXXXX</td> 4479 <td>-08:00<br> 4480 -07:52:58<br> 4481 Z</td> 4482 <td colspan="2">The <i>ISO8601 extended format</i> with 4483 hours, minutes and optional seconds fields. The ISO8601 UTC 4484 indicator "Z" is used when local time offset is 0. (The 4485 same as xxxxx, plus "Z".)<br> 4486 <i><b>Note</b>: The seconds field is not supported by the 4487 ISO8601 specification.</i></td> 4488 </tr> 4489 <tr> 4490 <td rowspan="5" style="text-align: center">x</td> 4491 <td style="text-align: center">x</td> 4492 <td>-08<br> 4493 +0530<br> 4494 +00</td> 4495 <td colspan="2">The <i>ISO8601 basic format</i> with hours 4496 field and optional minutes field. (The same as X, minus 4497 "Z".)</td> 4498 </tr> 4499 <tr> 4500 <td style="text-align: center">xx</td> 4501 <td>-0800<br> 4502 +0000</td> 4503 <td colspan="2">The <i>ISO8601 basic format</i> with hours 4504 and minutes fields. (The same as XX, minus "Z".)</td> 4505 </tr> 4506 <tr> 4507 <td style="text-align: center">xxx</td> 4508 <td>-08:00<br> 4509 +00:00</td> 4510 <td colspan="2">The <i>ISO8601 extended format</i> with 4511 hours and minutes fields. (The same as XXX, minus 4512 "Z".)</td> 4513 </tr> 4514 <tr> 4515 <td style="text-align: center">xxxx</td> 4516 <td>-0800<br> 4517 -075258<br> 4518 +0000</td> 4519 <td colspan="2">The <i>ISO8601 basic format</i> with hours, 4520 minutes and optional seconds fields. (The same as XXXX, 4521 minus "Z".)<br> 4522 <i><b>Note</b>: The seconds field is not supported by the 4523 ISO8601 specification.</i></td> 4524 </tr> 4525 <tr> 4526 <td style="text-align: center">xxxxx</td> 4527 <td>-08:00<br> 4528 -07:52:58<br> 4529 +00:00</td> 4530 <td colspan="2">The <i>ISO8601 extended format</i> with 4531 hours, minutes and optional seconds fields. (The same as 4532 XXXXX, minus "Z".)<br> 4533 <i><b>Note</b>: The seconds field is not supported by the 4534 ISO8601 specification.</i></td> 4535 </tr> 4536 </table> 4537 <h3>8.1 <a name="Localized_Pattern_Characters" href= 4538 "#Localized_Pattern_Characters" id= 4539 "Localized_Pattern_Characters">Localized Pattern Characters 4540 (deprecated)</a></h3> 4541 <p>These are characters that can be used when displaying a date 4542 pattern to an end user. This can occur, for example, when a 4543 spreadsheet allows users to specify date patterns. Whatever is 4544 in the string is substituted one-for-one with the characters 4545 "GyMdkHmsSEDFwWahKzYeugAZvcLQqVUOXxr", with the above meanings. 4546 Thus, for example, if 'J' is to be used instead of 'Y' to mean 4547 Year (for Week of Year), then the string would be: 4548 "GyMdkHmsSEDFwWahKz<u>J</u>eugAZvcLQqVUOXxr".</p> 4549 <p>This element is deprecated. It is recommended instead that a 4550 more sophisticated UI be used for localization, such as using 4551 icons to represent the different formats (and lengths) in the 4552 <a href="#Date_Field_Symbol_Table">Date Field Symbol 4553 Table</a>.</p> 4554 <h3>8.2 <a name="Date_Patterns_AM_PM" href= 4555 "#Date_Patterns_AM_PM" id="Date_Patterns_AM_PM">AM / 4556 PM</a></h3> 4557 <p>Even for countries where the customary date format only has 4558 a 24 hour format, both the am and pm localized strings must be 4559 present and must be distinct from one another. Note that as 4560 long as the 24 hour format is used, these strings will normally 4561 never be used, but for testing and unusual circumstances they 4562 must be present.</p> 4563 <h3>8.3 <a name="Date_Patterns_Eras" href="#Date_Patterns_Eras" 4564 id="Date_Patterns_Eras">Eras</a></h3> 4565 <p>There are only two values for era in the Gregorian calendar, 4566 with two common naming conventions (here in abbreviated form 4567 for English): "BC" and "AD", or "BCE" and "CE". These values 4568 can be translated into other languages, like "a.C." and and 4569 "d.C." for Spanish, but there are no other eras in the 4570 Gregorian calendar. Other calendars have a different numbers of 4571 eras. Care should be taken when translating the era names for a 4572 specific calendar.</p> 4573 <h3>8.4 <a name="Date_Patterns_Week_Of_Year" href= 4574 "#Date_Patterns_Week_Of_Year" id= 4575 "Date_Patterns_Week_Of_Year">Week of Year</a></h3> 4576 <p>Values calculated for the Week of Year field range from 1 to 4577 53 for the Gregorian calendar (they may have different ranges 4578 for other calendars). Week 1 for a year is the first week that 4579 contains at least the specified minimum number of days from 4580 that year. Weeks between week 1 of one year and week 1 of the 4581 following year are numbered sequentially from 2 to 52 or 53 (if 4582 needed). For example, January 1, 1998 was a Thursday. If the 4583 first day of the week is MONDAY and the minimum days in a week 4584 is 4 (these are the values reflecting ISO 8601 and many 4585 national standards), then week 1 of 1998 starts on December 29, 4586 1997, and ends on January 4, 1998. However, if the first day of 4587 the week is SUNDAY, then week 1 of 1998 starts on January 4, 4588 1998, and ends on January 10, 1998. The first three days of 4589 1998 are then part of week 53 of 1997.</p> 4590 <p>Values are similarly calculated for the Week of Month.</p> 4591 <h3>8.5 <a name="Date_Patterns_Week_Elements" href= 4592 "#Date_Patterns_Week_Elements" id= 4593 "Date_Patterns_Week_Elements">Week Elements</a></h3> 4594 <dl> 4595 <dt><b>firstDay</b></dt> 4596 <dd>A number indicating which day of the week is considered 4597 the 'first' day, for calendar purposes. Because the ordering 4598 of days may vary between calendar, keywords are used for this 4599 value, such as sun, mon, …. These values will be replaced by 4600 the localized name when they are actually used.</dd> 4601 <dt><b>minDays (Minimal Days in First Week)</b></dt> 4602 <dd>Minimal days required in the first week of a month or 4603 year. For example, if the first week is defined as one that 4604 contains at least one day, this value will be 1. If it must 4605 contain a full seven days before it counts as the first week, 4606 then the value would be 7.</dd> 4607 <dt><b>weekendStart, weekendEnd</b></dt> 4608 <dd>Indicates the day and time that the weekend starts or 4609 ends. As with firstDay, keywords are used instead of 4610 numbers.</dd> 4611 </dl> 4612 <h2>9 <a name="Parsing_Dates_Times" href="#Parsing_Dates_Times" 4613 id="Parsing_Dates_Times">Parsing Dates and Times</a></h2> 4614 <p>For general information on lenient parsing, see <a href= 4615 "tr35.html#Lenient_Parsing">Lenient Parsing</a> in the core 4616 specification. This section provides additional information 4617 specific to parsing of dates and times.</p> 4618 <p>Lenient parsing of date and time strings is especially 4619 complicated, due to the large number of possible fields and 4620 formats. The fields fall into two categories: numeric fields 4621 (hour, day of month, year, numeric month, and so on) and 4622 symbolic fields (era, quarter, month, weekday, AM/PM, time 4623 zone). In addition, the user may type in a date or time in a 4624 form that is significantly different from the normal format for 4625 the locale, and the application must use the locale information 4626 to figure out what the user meant. Input may well consist of 4627 nothing but a string of numbers with separators, for example, 4628 "09/05/02 09:57:33".</p> 4629 <p>The input can be separated into tokens: numbers, symbols, 4630 and literal strings. Some care must be taken due to ambiguity, 4631 for example, in the Japanese locale the symbol for March is "3 4632 月", which looks like a number followed by a literal. To avoid 4633 these problems, symbols should be checked first, and spaces 4634 should be ignored (except to delimit the tokens of the input 4635 string).</p> 4636 <p>The meaning of symbol fields should be easy to determine; 4637 the problem is determining the meaning of the numeric fields. 4638 Disambiguation will likely be most successful if it is based on 4639 heuristics. Here are some rules that can help:</p> 4640 <ul> 4641 <li>Always try the format string expected for the input text 4642 first. This is the only way to disambiguate 03/07 (March 4643 2007, a credit card expiration date) from 03/07 (March 7, a 4644 birthday).</li> 4645 <li>Attempt to match fields and literals against those in the 4646 format string, using loose matching of the tokens. In 4647 particular, Unicode normalization and case variants should be 4648 accepted. Alternate symbols can also be accepted where 4649 unambiguous: for example, “11.30 am”.</li> 4650 <li>When matching symbols, try the narrow, abbreviated, and 4651 full-width forms, including standalone forms if they are 4652 unique. You may want to allow prefix matches too, or 4653 diacritic-insensitive, again, as long as they are unique. For 4654 example, for a month, accept 9, 09, S, Se, Sep, Sept, Sept., 4655 and so on. For abbreviated symbols (e.g. names of eras, 4656 months, weekdays), allow matches both with and without an 4657 abbreviation marker such as period (or whatever else may be 4658 customary in the locale); abbreviated forms in the CLDR data 4659 may or may not have such a marker. 4660 <ul> 4661 <li>Note: While parsing of narrow date values (e.g. month 4662 or day names) may be required in order to obtain minimum 4663 information from a formatted date (for instance, the only 4664 month information may be in a narrow form), the results 4665 are not guaranteed; parsing of an ambiguous formatted 4666 date string may produce a result that differs from the 4667 date originally used to create the formatted string.</li> 4668 <li>For day periods, ASCII variants for AM/PM such as 4669 “am”, “a.m.”, “am.” (and their case variants) should be 4670 accepted, since they are widely used as alternates to 4671 native formats.</li> 4672 </ul> 4673 </li> 4674 <li>When a field or literal is encountered that is not 4675 compatible with the pattern: 4676 <ul> 4677 <li>Synchronization is not necessary for symbolic fields, 4678 since they are self-identifying. Wait until a numeric 4679 field or literal is encountered before attempting to 4680 resynchronize.</li> 4681 <li>Ignore whether the input token is symbolic or 4682 numeric, if it is compatible with the current field in 4683 the pattern.</li> 4684 <li>Look forward or backward in the current format string 4685 for a literal that matches the one most recently 4686 encountered. See if you can resynchronize from that 4687 point. Use the value of the numeric field to 4688 resynchronize as well, if possible (for example, a number 4689 larger than the largest month cannot be a month)</li> 4690 <li>If that fails, use other format strings from the 4691 locale (including those in <availableFormats>) to 4692 try to match the previous or next symbol or literal 4693 (again, using a loose match).</li> 4694 </ul> 4695 </li> 4696 </ul> 4697 <hr> 4698 <p class="copyright">Copyright © 2001–2020 Unicode, Inc. All 4699 Rights Reserved. The Unicode Consortium makes no expressed or 4700 implied warranty of any kind, and assumes no liability for 4701 errors or omissions. No liability is assumed for incidental and 4702 consequential damages in connection with or arising out of the 4703 use of the information or programs contained or accompanying 4704 this technical report. The Unicode <a href= 4705 "https://unicode.org/copyright.html">Terms of Use</a> apply.</p> 4706 <p class="copyright">Unicode and the Unicode logo are 4707 trademarks of Unicode, Inc., and are registered in some 4708 jurisdictions.</p> 4709 </div> 4710</body> 4711</html> 4712
