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