idnits 2.17.1 draft-murchison-rfc8536bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2021) is 1145 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '-89999' is mentioned on line 402, but not defined -- Looks like a reference, but probably isn't: '93599' on line 402 == Missing Reference: '-3599' is mentioned on line 1044, but not defined == Missing Reference: '-1' is mentioned on line 1044, but not defined -- Looks like a reference, but probably isn't: '0' on line 1542 -- Looks like a reference, but probably isn't: '1' on line 1428 -- Looks like a reference, but probably isn't: '2' on line 1431 -- Looks like a reference, but probably isn't: '3' on line 1411 -- Looks like a reference, but probably isn't: '4' on line 1412 -- Looks like a reference, but probably isn't: '5' on line 1413 -- Looks like a reference, but probably isn't: '6' on line 1363 -- Looks like a reference, but probably isn't: '7' on line 1122 -- Looks like a reference, but probably isn't: '8' on line 1437 -- Looks like a reference, but probably isn't: '9' on line 1132 -- Looks like a reference, but probably isn't: '10' on line 1137 -- Looks like a reference, but probably isn't: '11' on line 1142 -- Looks like a reference, but probably isn't: '12' on line 1398 -- Looks like a reference, but probably isn't: '13' on line 1152 -- Looks like a reference, but probably isn't: '14' on line 1157 -- Looks like a reference, but probably isn't: '15' on line 1162 -- Looks like a reference, but probably isn't: '16' on line 1399 -- Looks like a reference, but probably isn't: '17' on line 1172 -- Looks like a reference, but probably isn't: '18' on line 1177 -- Looks like a reference, but probably isn't: '19' on line 1182 -- Looks like a reference, but probably isn't: '20' on line 1187 -- Looks like a reference, but probably isn't: '21' on line 1231 -- Looks like a reference, but probably isn't: '22' on line 1197 -- Looks like a reference, but probably isn't: '23' on line 1202 -- Looks like a reference, but probably isn't: '24' on line 1207 -- Looks like a reference, but probably isn't: '25' on line 1212 -- Looks like a reference, but probably isn't: '26' on line 1217 -- Possible downref: Non-RFC (?) normative reference: ref. 'GNU-C' -- Possible downref: Non-RFC (?) normative reference: ref. 'POSIX' ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Possible downref: Non-RFC (?) normative reference: ref. 'ZIC' -- Duplicate reference: RFC8536, mentioned in 'Err6435', was also mentioned in 'Err6426'. -- Duplicate reference: RFC8536, mentioned in 'RFC8536', was also mentioned in 'Err6435'. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 34 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) A. Olson 3 Internet-Draft 4 Obsoletes: 8536 (if approved) P. Eggert 5 Intended status: Standards Track UCLA 6 Expires: September 9, 2021 K. Murchison 7 Fastmail 8 March 8, 2021 10 The Time Zone Information Format (TZif) 11 draft-murchison-rfc8536bis-00 13 Abstract 15 This document specifies the Time Zone Information Format (TZif) for 16 representing and exchanging time zone information, independent of any 17 particular service or protocol. Two media types for this format are 18 also defined. 20 This document replaces and obsoletes RFC 8536. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 9, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. The Time Zone Information Format (TZif) . . . . . . . . . . . 5 56 3.1. TZif Header . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2. TZif Data Block . . . . . . . . . . . . . . . . . . . . . 8 58 3.3. TZif Footer . . . . . . . . . . . . . . . . . . . . . . . 11 59 3.3.1. TZ String Extensions . . . . . . . . . . . . . . . . 12 60 4. Interoperability Considerations . . . . . . . . . . . . . . . 13 61 5. Use with the Time Zone Data Distribution Service . . . . . . 14 62 5.1. Truncating TZif Files . . . . . . . . . . . . . . . . . . 14 63 5.2. Example TZDIST Request for TZif Data . . . . . . . . . . 15 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 65 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 67 8.1. application/tzif . . . . . . . . . . . . . . . . . . . . 17 68 8.2. application/tzif-leap . . . . . . . . . . . . . . . . . . 18 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 71 9.2. Informative References . . . . . . . . . . . . . . . . . 20 72 Appendix A. Common Interoperability Issues . . . . . . . . . . . 21 73 Appendix B. Example TZif Files . . . . . . . . . . . . . . . . . 23 74 B.1. Version 1 File Representing UTC (with Leap Seconds) . . . 23 75 B.2. Version 2 File Representing Pacific/Honolulu . . . . . . 27 76 B.3. Truncated Version 3 File Representing Asia/Jerusalem . . 32 77 Appendix C. Changes from RFC 8536 . . . . . . . . . . . . . . . 34 78 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 34 79 D.1. Since RFC 8536 . . . . . . . . . . . . . . . . . . . . . 34 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 83 1. Introduction 85 Time zone data typically consists of offsets from universal time 86 (UT), daylight saving transition rules, one or more local time 87 designations (acronyms or abbreviations), and optional leap-second 88 adjustments. One such format for conveying this information is 89 iCalendar [RFC5545]. It is a text-based format used by calendaring 90 and scheduling systems. 92 This document specifies the widely deployed Time Zone Information 93 Format (TZif). It is a binary format used by most UNIX systems to 94 calculate local time. This format was introduced in the 1980s and 95 has evolved since then into multiple upward-compatible versions. 97 There is a wide variety of interoperable software capable of 98 generating and reading files in this format [tz-link]. 100 This specification does not define the source of the data assembled 101 into a TZif file. One such source is the IANA-hosted time zone 102 database [RFC6557]. 104 This document obsoletes RFC 8536, providing editorial improvements, 105 new details, and errata fixes while keeping full compatibility with 106 the interchange format of RFC 8536. It does not create a new version 107 of the format. The changes from RFC 8536 are summarized in 108 Appendix C. 110 2. Conventions Used in This Document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in 115 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 The following terms are used in this document (see "Sources for Time 119 Zone and Daylight Saving Time Data" [tz-link] for more detailed 120 information about civil timekeeping data and practice): 122 Coordinated Universal Time (UTC): The basis for civil time since 123 1960. It is approximately equal to mean solar time at the prime 124 meridian (0 degrees longitude). 126 Daylight Saving Time (DST): The time according to a location's law 127 or practice, when adjusted as necessary from standard time. The 128 adjustment may be positive or negative, and the amount of 129 adjustment may vary depending on the date and time; the TZif 130 format even allows the adjustment to be zero, although this is not 131 common practice. 133 International Atomic Time (TAI): The time standard based on atomic 134 clocks since 1972. It is equal to UTC but without leap-second 135 adjustments. 137 Leap-Second Correction (LEAPCORR): The value of TAI - UTC - 10 for 138 timestamps after the first leap second, and zero for timestamps 139 before that. The expression "TAI - UTC - 10" comes from the fact 140 that TAI - UTC was defined to be 10 just prior to the first leap 141 second in 1972, so clocks with leap seconds have a zero LEAPCORR 142 before the first leap second. 144 Local Time: Civil time for a particular location. Its offset from 145 universal time can depend on the date and time of day. 147 POSIX Epoch: 1970-01-01 00:00:00 UTC, the basis for absolute 148 timestamps in this document. 150 Standard Time: The time according to a location's law or practice, 151 unadjusted for Daylight Saving Time. 153 Time Change: A change to civil timekeeping practice. It occurs when 154 one or more of the following happen simultaneously: 156 1. a change in UT offset 158 2. a change in whether daylight saving time is in effect 160 3. a change in time zone abbreviation 162 4. a leap second (i.e., a change in LEAPCORR) 164 Time Zone Data: The Time Zone Data Distribution Service (TZDIST) 165 [RFC7808] defines "Time zone data" as "data that defines a single 166 time zone, including an identifier, UTC offset values, DST rules, 167 and other information such as time zone abbreviations." The 168 interchange format defined in this document is one such form of 169 time zone data. 171 Transition Time: The moment of occurrence of a time change that is 172 not a leap second. It is identified with a signed integer count 173 of UNIX leap time seconds since the POSIX epoch. 175 Universal Time (UT): The basis of civil time. This is the principal 176 form of the mean solar time at the prime meridian (0 degrees 177 longitude) for timestamps before UTC was introduced in 1960 and is 178 UTC for timestamps thereafter. Although UT is sometimes called 179 "UTC" or "GMT" in other sources, this specification uses the term 180 "UT" to avoid confusion with UTC or with GMT. 182 UNIX Time: The time as returned by the time() function provided by 183 the C programming language (see Section 3 of the "System 184 Interfaces" volume of [POSIX]). This is an integer number of 185 seconds since the POSIX epoch, not counting leap seconds. As an 186 extension to POSIX, negative values represent times before the 187 POSIX epoch, using UT. 189 UNIX Leap Time: UNIX time plus all preceding leap-second 190 corrections. For example, if the first leap-second record in a 191 TZif file occurs at 1972-06-30 23:59:60 UTC, the UNIX leap time 192 for the timestamp 1972-07-01 00:00:00 UTC would be 78796801, one 193 greater than the UNIX time for the same timestamp. Similarly, if 194 the second leap-second record occurs at 1972-12-31 23:59:60 UTC, 195 it accounts for the first leap second, so the UNIX leap time of 196 1972-12-31 23:59:60 UTC would be 94694401, and the UNIX leap time 197 of 1973-01-01 00:00:00 UTC would be 94694402. If a TZif file 198 specifies no leap-second records, UNIX leap time is equal to UNIX 199 time. 201 Wall Time: Another name for local time; short for "wall-clock time". 203 3. The Time Zone Information Format (TZif) 205 The Time Zone Information Format begins with a fixed 44-octet version 206 1 header (Section 3.1) containing a field that specifies the version 207 of the file's format. Readers designed for version N can read 208 version N+1 files without too much trouble; data specific to version 209 N+1 either appears after version N data so that earlier-version 210 readers can easily ignore later-version data they are not designed 211 for, or it appears as a minor extension to version N that version N 212 readers are likely to tolerate well. 214 The version 1 header is followed by a variable-length version 1 data 215 block (Section 3.2) containing four-octet (32-bit) transition times 216 and leap-second occurrences. These 32-bit values are limited to 217 representing time changes from 1901-12-13 20:45:52 through 2038-01-19 218 03:14:07 UT, and the version 1 header and data block are present only 219 for backward compatibility with obsolescent readers, as discussed in 220 Common Interoperability Issues (Appendix A). 222 Version 1 files terminate after the version 1 data block. Files from 223 versions 2 and 3 extend the format by appending a second 44-octet 224 version 2+ header, a variable-length version 2+ data block containing 225 eight-octet (64-bit) transition times and leap-second occurrences, 226 and a variable-length footer (Section 3.3). These 64-bit values can 227 represent times approximately 292 billion years into the past or 228 future. 230 NOTE: All multi-octet integer values MUST be stored in network octet 231 order format (high-order octet first, otherwise known as big-endian), 232 with all bits significant. Signed integer values MUST be represented 233 using two's complement. 235 A TZif file is structured as follows: 237 Version 1 Versions 2 & 3 238 +-------------+ +-------------+ 239 | Version 1 | | Version 1 | 240 | Header | | Header | 241 +-------------+ +-------------+ 242 | Version 1 | | Version 1 | 243 | Data Block | | Data Block | 244 +-------------+ +-------------+ 245 | Version 2+ | 246 | Header | 247 +-------------+ 248 | Version 2+ | 249 | Data Block | 250 +-------------+ 251 | Footer | 252 +-------------+ 254 General Format of TZif Files 256 3.1. TZif Header 258 A TZif header is structured as follows (the lengths of multi-octet 259 fields are shown in parentheses): 261 +---------------+---+ 262 | magic (4) |ver| 263 +---------------+---+---------------------------------------+ 264 | [unused - reserved for future use] (15) | 265 +---------------+---------------+---------------+-----------+ 266 | isutcnt (4) | isstdcnt (4) | leapcnt (4) | 267 +---------------+---------------+---------------+ 268 | timecnt (4) | typecnt (4) | charcnt (4) | 269 +---------------+---------------+---------------+ 271 TZif Header 273 The fields of the header are defined as follows: 275 magic: The four-octet ASCII [RFC20] sequence "TZif" (0x54 0x5A 0x69 276 0x66), which identifies the file as utilizing the Time Zone 277 Information Format. 279 ver(sion): An octet identifying the version of the file's format. 280 The value MUST be one of the following: 282 NUL (0x00) Version 1 - The file contains only the version 1 283 header and data block. Version 1 files MUST NOT contain a 284 version 2+ header, data block, or footer. 286 '2' (0x32) Version 2 - The file MUST contain the version 1 header 287 and data block, a version 2+ header and data block, and a 288 footer. The TZ string in the footer (Section 3.3), if 289 nonempty, MUST strictly adhere to the requirements for the TZ 290 environment variable as defined in Section 8.3 of the "Base 291 Definitions" volume of [POSIX] and MUST encode the POSIX 292 portable character set as ASCII. 294 '3' (0x33) Version 3 - The file MUST contain the version 1 header 295 and data block, a version 2+ header and data block, and a 296 footer. The TZ string in the footer (Section 3.3), if 297 nonempty, MUST conform to POSIX requirements with ASCII 298 encoding, except that it MAY use the TZ string extensions 299 described below (Section 3.3.1). 301 isutcnt: A four-octet unsigned integer specifying the number of UT/ 302 local indicators contained in the data block -- MUST either be 303 zero or equal to "typecnt". 305 isstdcnt: A four-octet unsigned integer specifying the number of 306 standard/wall indicators contained in the data block -- MUST 307 either be zero or equal to "typecnt". 309 leapcnt: A four-octet unsigned integer specifying the number of 310 leap-second records contained in the data block. 312 timecnt: A four-octet unsigned integer specifying the number of 313 transition times contained in the data block. 315 typecnt: A four-octet unsigned integer specifying the number of 316 local time type records contained in the data block -- MUST NOT be 317 zero. (Although local time type records convey no useful 318 information in files that have nonempty TZ strings but no 319 transitions, at least one such record is nevertheless required 320 because many TZif readers reject files that have zero time types.) 322 charcnt: A four-octet unsigned integer specifying the total number 323 of octets used by the set of time zone designations contained in 324 the data block - MUST NOT be zero. The count includes the 325 trailing NUL (0x00) octet at the end of the last time zone 326 designation. 328 Although the version 1 and 2+ headers have the same format, magic 329 number, and version fields, their count fields may differ, because 330 the version 1 data can be a subset of the version 2+ data. 332 3.2. TZif Data Block 334 A TZif data block consists of seven variable-length elements, each of 335 which is a series of items. The number of items in each series is 336 determined by the corresponding count field in the header. The total 337 length of each element is calculated by multiplying the number of 338 items by the size of each item. Therefore, implementations that do 339 not wish to parse or use the version 1 data block can calculate its 340 total length and skip directly to the header of the version 2+ data 341 block. 343 In the version 1 data block, time values are 32 bits (TIME_SIZE = 4 344 octets). In the version 2+ data block, present only in version 2 and 345 3 files, time values are 64 bits (TIME_SIZE = 8 octets). 347 The data block is structured as follows (the lengths of multi-octet 348 fields are shown in parentheses): 350 +---------------------------------------------------------+ 351 | transition times (timecnt x TIME_SIZE) | 352 +---------------------------------------------------------+ 353 | transition types (timecnt) | 354 +---------------------------------------------------------+ 355 | local time type records (typecnt x 6) | 356 +---------------------------------------------------------+ 357 | time zone designations (charcnt) | 358 +---------------------------------------------------------+ 359 | leap-second records (leapcnt x (TIME_SIZE + 4)) | 360 +---------------------------------------------------------+ 361 | standard/wall indicators (isstdcnt) | 362 +---------------------------------------------------------+ 363 | UT/local indicators (isutcnt) | 364 +---------------------------------------------------------+ 366 TZif Data Block 368 The elements of the data block are defined as follows: 370 transition times: A series of four- or eight-octet UNIX leap-time 371 values sorted in strictly ascending order. Each value is used as 372 a transition time at which the rules for computing local time may 373 change. The number of time values is specified by the "timecnt" 374 field in the header. Each time value SHOULD be at least -2**59. 375 (-2**59 is the greatest negated power of 2 that predates the Big 376 Bang, and avoiding earlier timestamps works around known TZif 377 reader bugs relating to outlandishly negative timestamps.) 379 transition types: A series of one-octet unsigned integers specifying 380 the type of local time of the corresponding transition time. 381 These values serve as zero-based indices into the array of local 382 time type records. The number of type indices is specified by the 383 "timecnt" field in the header. Each type index MUST be in the 384 range [0, "typecnt" - 1]. 386 local time type records: A series of six-octet records specifying a 387 local time type. The number of records is specified by the 388 "typecnt" field in the header. Each record has the following 389 format (the lengths of multi-octet fields are shown in 390 parentheses): 392 +---------------+---+---+ 393 | utoff (4) |dst|idx| 394 +---------------+---+---+ 396 utoff: A four-octet signed integer specifying the number of 397 seconds to be added to UT in order to determine local time. 398 The value MUST NOT be -2**31 and SHOULD be in the range 399 [-89999, 93599] (i.e., its value SHOULD be more than -25 hours 400 and less than 26 hours). Avoiding -2**31 allows 32-bit clients 401 to negate the value without overflow. Restricting it to 402 [-89999, 93599] allows easy support by implementations that 403 already support the POSIX-required range [-24:59:59, 25:59:59]. 405 (is)dst: A one-octet value indicating whether local time should 406 be considered Daylight Saving Time (DST). The value MUST be 0 407 or 1. A value of one (1) indicates that this type of time is 408 DST. A value of zero (0) indicates that this time type is 409 standard time. 411 (desig)idx: A one-octet unsigned integer specifying a zero-based 412 index into the series of time zone designation octets, thereby 413 selecting a particular designation string. Each index MUST be 414 in the range [0, "charcnt" - 1]; it designates the 415 NUL-terminated string of octets starting at position "idx" in 416 the time zone designations. (This string MAY be empty.) A NUL 417 octet MUST exist in the time zone designations at or after 418 position "idx". 420 time zone designations: A series of octets constituting an array of 421 NUL-terminated (0x00) time zone designation strings. The total 422 number of octets is specified by the "charcnt" field in the 423 header. Note that two designations MAY overlap if one is a suffix 424 of the other. The character encoding of time zone designation 425 strings is not specified; however, see Section 4 of this document. 427 leap-second records: A series of eight- or twelve-octet records 428 specifying the corrections that need to be applied to UTC in order 429 to determine TAI. The records are sorted by the occurrence time 430 in strictly ascending order. The number of records is specified 431 by the "leapcnt" field in the header. Each record has one of the 432 following structures (the lengths of multi-octet fields are shown 433 in parentheses): 435 Version 1 Data Block: 437 +---------------+---------------+ 438 | occur (4) | corr (4) | 439 +---------------+---------------+ 441 version 2+ Data Block: 443 +---------------+---------------+---------------+ 444 | occur (8) | corr (4) | 445 +---------------+---------------+---------------+ 447 occur(rence): A four- or eight-octet UNIX leap time value 448 specifying the time at which a leap-second correction occurs. 449 The first value, if present, MUST be nonnegative, and each 450 later value MUST be at least 2419199 greater than the previous 451 value. (This is 28 days' worth of seconds, minus a potential 452 negative leap second.) 454 corr(ection): A four-octet signed integer specifying the value of 455 LEAPCORR on or after the occurrence. The correction value in 456 the first leap-second record, if present, MUST be either one 457 (1) or minus one (-1). The correction values in adjacent leap- 458 second records MUST differ by exactly one (1). The value of 459 LEAPCORR is zero for timestamps that occur before the 460 occurrence time in the first leap-second record (or for all 461 timestamps if there are no leap-second records). 463 standard/wall indicators: A series of one-octet values indicating 464 whether the transition times associated with local time types were 465 specified as standard time or wall-clock time. Each value MUST be 466 0 or 1. A value of one (1) indicates standard time. The value 467 MUST be set to one (1) if the corresponding UT/local indicator is 468 set to one (1). A value of zero (0) indicates wall time. The 469 number of values is specified by the "isstdcnt" field in the 470 header. If "isstdcnt" is zero (0), all transition times 471 associated with local time types are assumed to be specified as 472 wall time. 474 UT/local indicators: A series of one-octet values indicating whether 475 the transition times associated with local time types were 476 specified as UT or local time. Each value MUST be 0 or 1. A 477 value of one (1) indicates UT, and the corresponding standard/wall 478 indicator MUST also be set to one (1). A value of zero (0) 479 indicates local time. The number of values is specified by the 480 "isutcnt" field in the header. If "isutcnt" is zero (0), all 481 transition times associated with local time types are assumed to 482 be specified as local time. 484 The type corresponding to a transition time specifies local time for 485 timestamps starting at the given transition time and continuing up 486 to, but not including, the next transition time. Local time for 487 timestamps before the first transition is specified by the first time 488 type (time type 0). Local time for timestamps on or after the last 489 transition is specified by the TZ string in the footer (Section 3.3) 490 if present and nonempty; otherwise, it is unspecified. If there are 491 no transitions, local time for all timestamps is specified by the TZ 492 string in the footer if present and nonempty; otherwise, it is 493 specified by time type 0. 495 A given pair of standard/wall and UT/local indicators is used to 496 designate whether the corresponding transition time was specified as 497 UT, standard time, or wall-clock time. Note that there are only 498 three combinations of the two indicators, given that the standard/ 499 wall value MUST be one (1) if the UT/local value is one (1). This 500 information can be useful if the transition times in a TZif file need 501 to be transformed into transitions appropriate for another time zone 502 (e.g. when calculating transition times for a simple POSIX-like TZ 503 string such as "AKST9AKDT"). 505 In order to eliminate unused space in a TZif file, every nonzero 506 local time type index SHOULD appear at least once in the transition 507 type array. Likewise, every octet in the time zone designations 508 array SHOULD be used by at least one time type record. 510 3.3. TZif Footer 512 The TZif footer is structured as follows (the lengths of multi-octet 513 fields are shown in parentheses): 515 +---+--------------------+---+ 516 | NL| TZ string (0...) |NL | 517 +---+--------------------+---+ 519 TZif Footer 521 The elements of the footer are defined as follows: 523 NL: An ASCII new line character (0x0A). 525 TZ string: A rule for computing local time changes after the last 526 transition time stored in the version 2+ data block. The string 527 is either empty or uses the expanded format of the "TZ" 528 environment variable as defined in Section 8.3 of the "Base 529 Definitions" volume of [POSIX] with ASCII encoding, possibly 530 utilizing extensions described below (Section 3.3.1) in version 3 531 files. If the string is empty, the corresponding information is 532 not available. If the string is nonempty and one or more 533 transitions appear in the version 2+ data, the string MUST be 534 consistent with the last version 2+ transition. In other words, 535 evaluating the TZ string at the time of the last transition should 536 yield the same time type as was specified in the last transition. 537 The string MUST NOT contain NUL octets or be NUL-terminated, and 538 it SHOULD NOT begin with the ':' (colon) character. 540 The TZif footer is present only in version 2 and 3 files, as the 541 obsolescent version 1 format was designed before the need for a 542 footer was apparent. 544 3.3.1. TZ String Extensions 546 The TZ string in a version 3 TZif file MAY use the following 547 extensions to POSIX TZ strings. These extensions are described using 548 the terminology of Section 8.3 of the "Base Definitions" volume of 549 [POSIX]. 551 o The hours part of the transition times may be signed and range 552 from -167 through 167 (-167 <= hh <= 167) instead of the POSIX- 553 required unsigned values from 0 through 24. 555 Example: <-03>3<-02>,M3.5.0/-2,M10.5.0/-1 556 This represents a time zone that observes daylight saving time 557 from 22:00 on the day before March's last Sunday until 23:00 on 558 the day before October's last Sunday. Standard time is 3 hours 559 west of UT and is abbreviated "-03"; daylight saving time is 2 560 hours west of UT and is abbreviated "-02". 562 o DST is considered to be in effect all year if it starts January 1 563 at 00:00 and ends December 31 at 24:00 plus the difference between 564 daylight saving and standard time, leaving no room for standard 565 time in the calendar. 567 Example: EST5EDT,0/0,J365/25 568 This represents a time zone that observes daylight saving time 569 all year. It is 4 hours west of UT and is abbreviated "EDT". 570 The "EST" is ignored. 572 Example: XXX3EDT4,0/0,J365/23 573 This represents the same time zone as the previous example. It 574 uses a DST further west of UTC than standard time. The "XXX" 575 is ignored. 577 4. Interoperability Considerations 579 The following practices help ensure the interoperability of TZif 580 applications. 582 o Version 1 files are considered a legacy format and SHOULD NOT be 583 generated, as they do not support transition times after the year 584 2038. 586 o Implementations that only understand version 1 MUST ignore any 587 data that extends beyond the calculated end of the version 1 data 588 block. 590 o Implementations SHOULD generate a version 3 file if TZ string 591 extensions are necessary to accurately model transition times. 592 Otherwise, version 2 files SHOULD be generated. 594 o The sequence of time changes defined by the version 1 header and 595 data block SHOULD be a contiguous sub-sequence of the time changes 596 defined by the version 2+ header and data block, and by the 597 footer. This guideline helps obsolescent version 1 readers agree 598 with current readers about timestamps within the contiguous sub- 599 sequence. It also lets writers not supporting obsolescent readers 600 use a "timecnt" of zero in the version 1 data block to save space. 602 o Time zone designations SHOULD consist of at least three (3) and no 603 more than six (6) ASCII characters from the set of alphanumerics, 604 '-', and '+'. This is for compatibility with POSIX requirements 605 for time zone abbreviations. 607 o When reading a version 2 or 3 file, implementations SHOULD ignore 608 the version 1 header and data block except for the purpose of 609 skipping over them. 611 o Implementations SHOULD calculate the total lengths of the headers 612 and data blocks and check that they all fit within the actual file 613 size, as part of a validity check for the file. 615 o When a TZif file is used in a MIME message entity, it SHOULD be 616 indicated by one of the following media types: 618 * "application/tzif-leap" (Section 8.2) to indicate that leap- 619 second records are included in the TZif data as necessary (none 620 are necessary if the file is truncated to a range that precedes 621 the first leap second). 623 * "application/tzif" (Section 8.1) to indicate that leap-second 624 records are not included in the TZif data; "leapcnt" in the 625 header(s) MUST be zero (0). 627 o Common interoperability issues and possible workarounds are 628 described in Appendix A. 630 5. Use with the Time Zone Data Distribution Service 632 The Time Zone Data Distribution Service (TZDIST) [RFC7808] is a 633 service that allows reliable, secure, and fast delivery of time zone 634 data and leap-second rules to client systems such as calendaring and 635 scheduling applications or operating systems. 637 A TZDIST service MAY supply time zone data to clients in the Time 638 Zone Information Format. Such a service MUST indicate that it 639 supports this format by including the media type "application/tzif" 640 (Section 8.1) in its "capabilities" response (see Section 5.1 of 641 [RFC7808]). A TZDIST service MAY also include the media type 642 "application/tzif-leap" (Section 8.2) in its "capabilities" response 643 if it is able to generate TZif files containing leap-second records. 644 A TZDIST service MUST NOT advertise the "application/tzif-leap" media 645 type without also advertising "application/tzif". 647 TZDIST clients MUST use the HTTP "Accept" [RFC7231] header field to 648 indicate their preference to receive data in the "application/tzif" 649 and/or "application/tzif-leap" formats. 651 5.1. Truncating TZif Files 653 As described in Section 3.9 of [RFC7808], a TZDIST service MAY 654 truncate time zone transition data. A truncated TZif file is valid 655 from its first and up to, but not including, its last version 2+ 656 transition time, if present. 658 When truncating the start of a TZif file, the service MUST supply in 659 the version 2+ data a first transition time that is the start point 660 of the truncation range. As with untruncated TZif files, time type 0 661 indicates local time immediately before the start point, and the time 662 type of the first transition indicates local time thereafter. 664 When truncating the end of a TZif file, the service MUST supply in 665 the version 2+ data a last transition time that is the end point of 666 the truncation range and MUST supply an empty TZ string. As with 667 untruncated TZif files with empty TZ strings, a truncated TZif file 668 does not indicate local time after the last transition. 670 All represented information that falls inside the truncation range 671 MUST be the same as that represented by a corresponding untruncated 672 TZif file. 674 TZDIST clients SHOULD NOT use a truncated TZif file (as described 675 above) to interpret timestamps outside the truncation time range. 677 5.2. Example TZDIST Request for TZif Data 679 In this example, the client checks the server for the available 680 formats and then requests that the time zone with a specific time 681 zone identifier be returned in Time Zone Information Format. 683 Note that this example presumes that the time zone context path has 684 been discovered (see [RFC7808], Section 4.2.1) to be "/tzdist". 686 >> Request << 688 GET /tzdist/capabilities HTTP/1.1 689 Host: tz.example.com 691 >> Response << 693 HTTP/1.1 200 OK 694 Date: Fri, 01 Jun 2018 14:52:23 GMT 695 Content-Type: application/json 696 Content-Length: xxxx 698 { 699 "version": 1, 701 "info": { 702 "primary-source": "IANA:2018e", 703 "formats": [ 704 "text/calendar", 705 "application/tzif", 706 "application/tzif-leap" 707 ], 708 ... 709 }, 710 ... 711 } 713 >> Request << 715 GET /tzdist/zones/America%2FNew_York HTTP/1.1 716 Host: tz.example.com 717 Accept: application/tzif 719 >> Response << 721 HTTP/1.1 200 OK 722 Date: Fri, 01 Jun 2018 14:52:24 GMT 723 Content-Type: application/tzif 724 Content-Length: xxxx 725 ETag: "123456789-000-111" 727 TZif2...[binary data without leap-second records]... 728 EST5EDT,M3.2.0,M11.1.0 730 6. Security Considerations 732 The Time Zone Information Format contains no executable code, and it 733 does not define any extensible areas that could be used to store such 734 code. 736 TZif contains counted arrays of data elements. All counts should be 737 checked when processing TZif objects, to guard against references 738 past the end of the object. 740 TZif provides no confidentiality or integrity protection. Time zone 741 information is normally public and does not call for confidentiality 742 protection. Since time zone information is used in many critical 743 applications, integrity protection may be required and must be 744 provided externally. 746 7. Privacy Considerations 748 The Time Zone Information Format contains publicly available data, 749 and it does not define any extensible areas that could be used to 750 store private data. 752 As discussed in Section 9 of [RFC7808], transmission of time zone 753 data over an insecure communications channel could leak the past, 754 current, or future location of a device or user. As such, TZif data 755 transmitted over a public communications channel MUST be protected 756 with a confidentiality layer such as that provided by Transport Layer 757 Security (TLS) [RFC8446]. 759 8. IANA Considerations 761 This document defines two media types [RFC6838] for the exchange of 762 data utilizing the Time Zone Information Format. 764 8.1. application/tzif 766 Type name: application 768 Subtype name: tzif 770 Required parameters: none 772 Optional parameters: none 774 Encoding considerations: binary 776 Security considerations: See Section 6 of RFC XXXX. 778 Interoperability considerations: See Section 4 of RFC XXXX. 780 Published specification: This specification. 782 Applications that use this media type: This media type is designed 783 for widespread use by applications that need to use or exchange 784 time zone information, such as the Time Zone Information Compiler 785 (zic) [ZIC] and the GNU C Library [GNU-C]. The Time Zone 786 Distribution Service [RFC7808] can directly use this media type. 788 Fragment identifier considerations: N/A 790 Additional information: 792 Magic number(s): The first 4 octets are 0x54, 0x5A, 0x69, 0x66 794 File extensions(s): N/A 796 Macintosh file type code(s): N/A 798 Person & email address to contact for further information: 799 Time Zone Database mailing list 801 Intended usage: COMMON 803 Restrictions on usage: N/A 805 Author: See the "Authors' Addresses" section of RFC XXXX. 807 Change controller: IETF 809 8.2. application/tzif-leap 811 Type name: application 813 Subtype name: tzif-leap 815 Required parameters: none 817 Optional parameters: none 819 Encoding considerations: binary 821 Security considerations: See Section 6 of RFC XXXX. 823 Interoperability considerations: See Section 4 of RFC XXXX. 825 Published specification: This specification. 827 Applications that use this media type: This media type is designed 828 for widespread use by applications that need to use or exchange 829 time zone information, such as the Time Zone Information Compiler 830 (zic) [ZIC] and the GNU C Library [GNU-C]. The Time Zone 831 Distribution Service [RFC7808] can directly use this media type. 833 Fragment identifier considerations: N/A 835 Additional information: 837 Magic number(s): The first 4 octets are 0x54, 0x5A, 0x69, 0x66 839 File extensions(s): N/A 841 Macintosh file type code(s): N/A 843 Person & email address to contact for further information: 844 Time Zone Database mailing list 846 Intended usage: COMMON 848 Restrictions on usage: N/A 850 Author: See the "Authors' Addresses" section of RFC XXXX. 852 Change controller: IETF 854 9. References 856 9.1. Normative References 858 [GNU-C] "The GNU C Library (glibc)", 859 . 861 [POSIX] IEEE, "Standard for Information Technology--Portable 862 Operating System Interface (POSIX(R)) Base Specifications, 863 Issue 7", IEEE 1003.1-2017, 864 DOI 10.1109/IEEESTD.2018.8277153, January 2018, 865 . 867 [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, 868 RFC 20, DOI 10.17487/RFC0020, October 1969, 869 . 871 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 872 Requirement Levels", BCP 14, RFC 2119, 873 DOI 10.17487/RFC2119, March 1997, 874 . 876 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 877 Specifications and Registration Procedures", BCP 13, 878 RFC 6838, DOI 10.17487/RFC6838, January 2013, 879 . 881 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 882 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 883 DOI 10.17487/RFC7231, June 2014, 884 . 886 [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution 887 Service", RFC 7808, DOI 10.17487/RFC7808, March 2016, 888 . 890 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 891 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 892 May 2017, . 894 [ZIC] Kerrisk, M., "ZIC(8)", man-pages release 4.16, February 895 2010, . 897 9.2. Informative References 899 [EGGERT-TZ] 900 "History for tz", March 2021, 901 . 903 [Err6426] RFC Errata, "Erratum ID 6426", RFC 8536, 904 . 906 [Err6435] RFC Errata, "Erratum ID 6435", RFC 8536, 907 . 909 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 910 Scheduling Core Object Specification (iCalendar)", 911 RFC 5545, DOI 10.17487/RFC5545, September 2009, 912 . 914 [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the 915 Time Zone Database", BCP 175, RFC 6557, 916 DOI 10.17487/RFC6557, February 2012, 917 . 919 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 920 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 921 . 923 [RFC8536] Olson, A., Eggert, P., and K. Murchison, "The Time Zone 924 Information Format (TZif)", RFC 8536, 925 DOI 10.17487/RFC8536, February 2019, 926 . 928 [tz-link] Eggert, P. and A. Olson, "Sources for Time Zone and 929 Daylight Saving Time Data", 2018, 930 . 932 Appendix A. Common Interoperability Issues 934 This section documents common problems in implementing this 935 specification. Most of these are problems in generating TZif files 936 for use by readers conforming to predecessors of this specification 937 [EGGERT-TZ]. The goals of this section are: 939 1. to help TZif writers output files that avoid common pitfalls in 940 older or buggy TZif readers, 942 2. to help TZif readers avoid common pitfalls when reading files 943 generated by future TZif writers, and 945 3. to help any future specification authors see what sort of 946 problems arise when the TZif format is changed. 948 When new versions of the TZif format have been defined, a design goal 949 has been that a reader can successfully use a TZif file even if the 950 file is of a later TZif version than what the reader was designed 951 for. When complete compatibility was not achieved, an attempt was 952 made to limit glitches to rarely used timestamps and allow simple 953 partial workarounds in writers designed to generate new-version data 954 useful even for older-version readers. This section attempts to 955 document these compatibility issues and workarounds, as well as 956 documenting other common bugs in readers. 958 Interoperability problems with TZif include the following: 960 o Some readers examine only version 1 data. As a partial 961 workaround, a writer can output as much version 1 data as 962 possible. However, a reader should ignore version 1 data and use 963 version 2+ data, even if the reader's native timestamps have only 964 32 bits. 966 o Some readers designed for version 2 might mishandle timestamps 967 after a version 3 file's last transition, because they cannot 968 parse extensions to POSIX in the TZ-like string. As a partial 969 workaround, a writer can output more transitions than necessary, 970 so that only far-future timestamps are mishandled by version 2 971 readers. 973 o Some readers designed for version 2 do not support permanent 974 daylight saving time -- e.g., a TZ string "EST5EDT,0/0,J365/25" 975 denoting permanent Eastern Daylight Time (-04). As a partial 976 workaround, a writer can substitute standard time for the next 977 time zone east -- e.g., "AST4" for permanent Atlantic Standard 978 Time (-04). 980 o Some readers ignore the footer and instead predict future 981 timestamps from the time type of the last transition. As a 982 partial workaround, a writer can output more transitions than 983 necessary. 985 o Some readers do not use time type 0 for timestamps before the 986 first transition, in that they infer a time type using a heuristic 987 that does not always select time type 0. As a partial workaround, 988 a writer can output a dummy (no-op) first transition at an early 989 time. 991 o Some readers mishandle timestamps before the first transition that 992 has a timestamp not less than -2**31. Readers that support only 993 32-bit timestamps are likely to be more prone to this problem, for 994 example, when they process 64-bit transitions, only some of which 995 are representable in 32 bits. As a partial workaround, a writer 996 can output a dummy transition at timestamp -2**31. 998 o Some readers mishandle a transition if its timestamp has the 999 minimum possible signed 64-bit value. Timestamps less than -2**59 1000 are not recommended. 1002 o Some readers mishandle POSIX-style TZ strings that contain "<" or 1003 ">". As a partial workaround, a writer can avoid using '<' or '>' 1004 for time zone abbreviations containing only alphabetic characters. 1006 o Many readers mishandle time zone abbreviations that contain non- 1007 ASCII characters. These characters are not recommended. 1009 o Some readers may mishandle time zone abbreviations that contain 1010 fewer than 3 or more than 6 characters, or that contain ASCII 1011 characters other than alphanumerics, '-', and '+'. These 1012 abbreviations are not recommended. 1014 o Some readers mishandle TZif files that specify daylight saving 1015 time UT offsets that are less than the UT offsets for the 1016 corresponding standard time. These readers do not support 1017 locations like Ireland, which uses the equivalent of the POSIX TZ 1018 string "IST-1GMT0,M10.5.0,M3.5.0/1", observing standard time (IST, 1019 +01) in summer and daylight saving time (GMT, +00) in winter. As 1020 a partial workaround, a writer can output data for the equivalent 1021 of the POSIX TZ string "GMT0IST,M3.5.0/1,M10.5.0", thus swapping 1022 standard and daylight saving time. Although this workaround 1023 misidentifies which part of the year uses daylight saving time, it 1024 records UT offsets and time zone abbreviations correctly. 1026 Some interoperability problems are reader bugs that are listed here 1027 mostly as warnings to developers of readers. 1029 o Some readers do not support negative timestamps. Developers of 1030 distributed applications should keep this in mind if they need to 1031 deal with pre-1970 data. 1033 o Some readers mishandle timestamps before the first transition that 1034 has a nonnegative timestamp. Readers that do not support negative 1035 timestamps are likely to be more prone to this problem. 1037 o Some readers mishandle time zone abbreviations like "-08" that 1038 contain '+', '-', or digits. 1040 o Some readers mishandle UT offsets that are out of the traditional 1041 range of -12 through +12 hours and so do not support locations 1042 like Kiritimati that are outside this range. 1044 o Some readers mishandle UT offsets in the range [-3599, -1] seconds 1045 from UT, because they integer-divide the offset by 3600 to get 0 1046 and then display the hour part as "+00". 1048 o Some readers mishandle UT offsets that are not a multiple of one 1049 hour, 15 minutes, or 1 minute. 1051 Appendix B. Example TZif Files 1053 The following sections contain annotated hexadecimal dumps of example 1054 TZif files. 1056 Note that these examples should only be considered informative. 1057 Although the example data entries are current as of the publication 1058 date of this document, the data will likely change in the future as 1059 leap seconds are added and changes are made to civil time. 1061 B.1. Version 1 File Representing UTC (with Leap Seconds) 1063 +--------+--------------+------------------+------------------------+ 1064 | File | Hexadecimal | Record Name / | Field Value | 1065 | Offset | Octets | Field Name | | 1066 +--------+--------------+------------------+------------------------+ 1067 | 000 | 54 5a 69 66 | magic | "TZif" | 1068 | 004 | 00 | version | 0 (1) | 1069 | 005 | 00 00 00 00 | | | 1070 | | 00 00 00 00 | | | 1071 | | 00 00 00 00 | | | 1072 | | 00 00 00 | | | 1073 | 020 | 00 00 00 01 | isutcnt | 1 | 1074 | 024 | 00 00 00 01 | isstdcnt | 1 | 1075 | 028 | 00 00 00 1b | leapcnt | 27 | 1076 | 032 | 00 00 00 00 | timecnt | 0 | 1077 | 036 | 00 00 00 01 | typecnt | 1 | 1078 | 040 | 00 00 00 04 | charcnt | 4 | 1079 | | | | | 1080 | | | localtimetype[0] | | 1081 | 044 | 00 00 00 00 | utoff | 0 (+00:00) | 1082 | 048 | 00 | isdst | 0 (no) | 1083 | 049 | 00 | desigidx | 0 | 1084 | | | | | 1085 | 050 | 55 54 43 00 | designations[0] | "UTC" | 1086 | | | | | 1087 | | | leapsecond[0] | | 1088 | 054 | 04 b2 58 00 | occurrence | 78796800 | 1089 | | | | (1972-06-30T23:59:60Z) | 1090 | 058 | 00 00 00 01 | correction | 1 | 1091 | | | | | 1092 | | | leapsecond[1] | | 1093 | 062 | 05 a4 ec 01 | occurrence | 94694401 | 1094 | | | | (1972-12-31T23:59:60Z) | 1095 | 066 | 00 00 00 02 | correction | 2 | 1096 | | | | | 1097 | | | leapsecond[2] | | 1098 | 070 | 07 86 1f 82 | occurrence | 126230402 | 1099 | | | | (1973-12-31T23:59:60Z) | 1100 | 074 | 00 00 00 03 | correction | 3 | 1101 | | | | | 1102 | | | leapsecond[3] | | 1103 | 078 | 09 67 53 03 | occurrence | 157766403 | 1104 | | | | (1974-12-31T23:59:60Z) | 1105 | 082 | 00 00 00 04 | correction | 4 | 1106 | | | | | 1107 | | | leapsecond[4] | | 1108 | 086 | 0b 48 86 84 | occurrence | 189302404 | 1109 | | | | (1975-12-31T23:59:60Z) | 1110 | 090 | 00 00 00 05 | correction | 5 | 1111 | | | | | 1112 | | | leapsecond[5] | | 1113 | 094 | 0d 2b 0b 85 | occurrence | 220924805 | 1114 | | | | (1976-12-31T23:59:60Z) | 1115 | 098 | 00 00 00 06 | correction | 6 | 1116 | | | | | 1117 | | | leapsecond[6] | | 1118 | 102 | 0f 0c 3f 06 | occurrence | 252460806 | 1119 | | | | (1977-12-31T23:59:60Z) | 1120 | 106 | 00 00 00 07 | correction | 7 | 1121 | | | | | 1122 | | | leapsecond[7] | | 1123 | 110 | 10 ed 72 87 | occurrence | 283996807 | 1124 | | | | (1978-12-31T23:59:60Z) | 1125 | 114 | 00 00 00 08 | correction | 8 | 1126 | | | | | 1127 | | | leapsecond[8] | | 1128 | 118 | 12 ce a6 08 | occurrence | 315532808 | 1129 | | | | (1979-12-31T23:59:60Z) | 1130 | 122 | 00 00 00 09 | correction | 9 | 1131 | | | | | 1132 | | | leapsecond[9] | | 1133 | 126 | 15 9f ca 89 | occurrence | 362793609 | 1134 | | | | (1981-06-30T23:59:60Z) | 1135 | 130 | 00 00 00 0a | correction | 10 | 1136 | | | | | 1137 | | | leapsecond[10] | | 1138 | 134 | 17 80 fe 0a | occurrence | 394329610 | 1139 | | | | (1982-06-30T23:59:60Z) | 1140 | 138 | 00 00 00 0b | correction | 11 | 1141 | | | | | 1142 | | | leapsecond[11] | | 1143 | 142 | 19 62 31 8b | occurrence | 425865611 | 1144 | | | | (1983-06-30T23:59:60Z) | 1145 | 146 | 00 00 00 0c | correction | 12 | 1146 | | | | | 1147 | | | leapsecond[12] | | 1148 | 150 | 1d 25 ea 0c | occurrence | 489024012 | 1149 | | | | (1985-06-30T23:59:60Z) | 1150 | 154 | 00 00 00 0d | correction | 13 | 1151 | | | | | 1152 | | | leapsecond[13] | | 1153 | 158 | 21 da e5 0d | occurrence | 567993613 | 1154 | | | | (1987-12-31T23:59:60Z) | 1155 | 162 | 00 00 00 0e | correction | 14 | 1156 | | | | | 1157 | | | leapsecond[14] | | 1158 | 166 | 25 9e 9d 8e | occurrence | 631152014 | 1159 | | | | (1989-12-31T23:59:60Z) | 1160 | 170 | 00 00 00 0f | correction | 15 | 1161 | | | | | 1162 | | | leapsecond[15] | | 1163 | 174 | 27 7f d1 0f | occurrence | 662688015 | 1164 | | | | (1990-12-31T23:59:60Z) | 1165 | 178 | 00 00 00 10 | correction | 16 | 1166 | | | | | 1167 | | | leapsecond[16] | | 1168 | 182 | 2a 50 f5 90 | occurrence | 709948816 | 1169 | | | | (1992-06-30T23:59:60Z) | 1170 | 186 | 00 00 00 11 | correction | 17 | 1171 | | | | | 1172 | | | leapsecond[17] | | 1173 | 190 | 2c 32 29 11 | occurrence | 741484817 | 1174 | | | | (1993-06-30T23:59:60Z) | 1175 | 194 | 00 00 00 12 | correction | 18 | 1176 | | | | | 1177 | | | leapsecond[18] | | 1178 | 198 | 2e 13 5c 92 | occurrence | 773020818 | 1179 | | | | (1994-06-30T23:59:60Z) | 1180 | 202 | 00 00 00 13 | correction | 19 | 1181 | | | | | 1182 | | | leapsecond[19] | | 1183 | 206 | 30 e7 24 13 | occurrence | 820454419 | 1184 | | | | (1995-12-31T23:59:60Z) | 1185 | 210 | 00 00 00 14 | correction | 20 | 1186 | | | | | 1187 | | | leapsecond[20] | | 1188 | 214 | 33 b8 48 94 | occurrence | 867715220 | 1189 | | | | (1997-06-30T23:59:60Z) | 1190 | 218 | 00 00 00 15 | correction | 21 | 1191 | | | | | 1192 | | | leapsecond[21] | | 1193 | 222 | 36 8c 10 15 | occurrence | 915148821 | 1194 | | | | (1998-12-31T23:59:60Z) | 1195 | 226 | 00 00 00 16 | correction | 22 | 1196 | | | | | 1197 | | | leapsecond[22] | | 1198 | 230 | 43 b7 1b 96 | occurrence | 1136073622 | 1199 | | | | (2005-12-31T23:59:60Z) | 1200 | 234 | 00 00 00 17 | correction | 23 | 1201 | | | | | 1202 | | | leapsecond[23] | | 1203 | 238 | 49 5c 07 97 | occurrence | 1230768023 | 1204 | | | | (2008-12-31T23:59:60Z) | 1205 | 242 | 00 00 00 18 | correction | 24 | 1206 | | | | | 1207 | | | leapsecond[24] | | 1208 | 246 | 4f ef 93 18 | occurrence | 1341100824 | 1209 | | | | (2012-06-30T23:59:60Z) | 1210 | 250 | 00 00 00 19 | correction | 25 | 1211 | | | | | 1212 | | | leapsecond[25] | | 1213 | 254 | 55 93 2d 99 | occurrence | 1435708825 | 1214 | | | | (2015-06-30T23:59:60Z) | 1215 | 258 | 00 00 00 1a | correction | 26 | 1216 | | | | | 1217 | | | leapsecond[26] | | 1218 | 262 | 58 68 46 9a | occurrence | 1483228826 | 1219 | | | | (2016-12-31T23:59:60Z) | 1220 | 266 | 00 00 00 1b | correction | 27 | 1221 | | | | | 1222 | 270 | 00 | standard/wall[0] | 0 (wall) | 1223 | | | | | 1224 | 271 | 00 | UT/local[0] | 0 (local) | 1225 +--------+--------------+------------------+------------------------+ 1227 To determine TAI corresponding to 2000-01-01T00:00:00Z 1228 (UNIX time = 946684800), the following procedure would be followed: 1230 1. Find the latest leap-second occurrence prior to the time of 1231 interest (leapsecond[21]) and note the correction value 1232 (LEAPCORR = 22). 1234 2. Add LEAPCORR + 10 to the time of interest to yield TAI of 1235 2000-01-01T00:00:32. 1237 B.2. Version 2 File Representing Pacific/Honolulu 1239 +--------+--------------+------------------+------------------------+ 1240 | File | Hexadecimal | Record Name / | Field Value | 1241 | Offset | Octets | Field Name | | 1242 +--------+--------------+------------------+------------------------+ 1243 | 000 | 54 5a 69 66 | magic | "TZif" | 1244 | 004 | 32 | version | '2' (2) | 1245 | 005 | 00 00 00 00 | | | 1246 | | 00 00 00 00 | | | 1247 | | 00 00 00 00 | | | 1248 | | 00 00 00 | | | 1249 | 020 | 00 00 00 06 | isutcnt | 6 | 1250 | 024 | 00 00 00 06 | isstdcnt | 6 | 1251 | 028 | 00 00 00 00 | leapcnt | 0 | 1252 | 032 | 00 00 00 07 | timecnt | 7 | 1253 | 036 | 00 00 00 06 | typecnt | 6 | 1254 | 040 | 00 00 00 14 | charcnt | 20 | 1255 | | | | | 1256 | 044 | 80 00 00 00 | trans time[0] | -2147483648 | 1257 | | | | (1901-12-13T20:45:52Z) | 1258 | 048 | bb 05 43 48 | trans time[1] | -1157283000 | 1259 | | | | (1933-04-30T12:30:00Z) | 1260 | 052 | bb 21 71 58 | trans time[2] | -1155436200 | 1261 | | | | (1933-05-21T21:30:00Z) | 1262 | 056 | cb 89 3d c8 | trans time[3] | -880198200 | 1263 | | | | (1942-02-09T12:30:00Z) | 1264 | 060 | d2 23 f4 70 | trans time[4] | -769395600 | 1265 | | | | (1945-08-14T23:00:00Z) | 1266 | 064 | d2 61 49 38 | trans time[5] | -765376200 | 1267 | | | | (1945-09-30T11:30:00Z) | 1268 | 068 | d5 8d 73 48 | trans time[6] | -712150200 | 1269 | | | | (1947-06-08T12:30:00Z) | 1270 | | | | | 1271 | 072 | 01 | trans type[0] | 1 | 1272 | 073 | 02 | trans type[1] | 2 | 1273 | 074 | 01 | trans type[2] | 1 | 1274 | 075 | 03 | trans type[3] | 3 | 1275 | 076 | 04 | trans type[4] | 4 | 1276 | 077 | 01 | trans type[5] | 1 | 1277 | 078 | 05 | trans type[6] | 5 | 1278 | | | | | 1279 | | | localtimetype[0] | | 1280 | 079 | ff ff 6c 02 | utoff | -37886 (-10:21:26) | 1281 | 083 | 00 | isdst | 0 (no) | 1282 | 084 | 00 | desigidx | 0 | 1283 | | | | | 1284 | | | localtimetype[1] | | 1285 | 085 | ff ff 6c 58 | utoff | -37800 (-10:30) | 1286 | 089 | 00 | isdst | 0 (no) | 1287 | 090 | 04 | desigidx | 4 | 1288 | | | | | 1289 | | | localtimetype[2] | | 1290 | 091 | ff ff 7a 68 | utoff | -34200 (-09:30) | 1291 | 095 | 01 | isdst | 1 (yes) | 1292 | 096 | 08 | desigidx | 8 | 1293 | | | | | 1294 | | | localtimetype[3] | | 1295 | 097 | ff ff 7a 68 | utoff | -34200 (-09:30) | 1296 | 101 | 01 | isdst | 1 (yes) | 1297 | 102 | 0c | desigidx | 12 | 1298 | | | | | 1299 | | | localtimetype[4] | | 1300 | 103 | ff ff 7a 68 | utoff | -34200 (-09:30) | 1301 | 107 | 01 | isdst | 1 (yes) | 1302 | 108 | 10 | desigidx | 16 | 1303 | | | | | 1304 | | | localtimetype[5] | | 1305 | 109 | ff ff 73 60 | utoff | -36000 (-10:00) | 1306 | 113 | 00 | isdst | 0 (no) | 1307 | 114 | 04 | desigidx | 4 | 1308 | | | | | 1309 | 115 | 4c 4d 54 00 | designations[0] | "LMT" | 1310 | 119 | 48 53 54 00 | designations[4] | "HST" | 1311 | 123 | 48 44 54 00 | designations[8] | "HDT" | 1312 | 127 | 48 57 54 00 | designations[12] | "HWT" | 1313 | 131 | 48 50 54 00 | designations[16] | "HPT" | 1314 | | | | | 1315 | 135 | 00 | standard/wall[0] | 0 (wall) | 1316 | 136 | 00 | standard/wall[1] | 0 (wall) | 1317 | 137 | 00 | standard/wall[2] | 0 (wall) | 1318 | 138 | 00 | standard/wall[3] | 0 (wall) | 1319 | 139 | 01 | standard/wall[4] | 1 (standard) | 1320 | 140 | 00 | standard/wall[5] | 0 (wall) | 1321 | | | | | 1322 | 141 | 00 | UT/local[0] | 0 (local) | 1323 | 142 | 00 | UT/local[1] | 0 (local) | 1324 | 143 | 00 | UT/local[2] | 0 (local) | 1325 | 144 | 00 | UT/local[3] | 0 (local) | 1326 | 145 | 01 | UT/local[4] | 1 (UT) | 1327 | 146 | 00 | UT/local[5] | 0 (local) | 1328 | | | | | 1329 | 147 | 54 5a 69 66 | magic | "TZif" | 1330 | 151 | 32 | version | '2' (2) | 1331 | 152 | 00 00 00 00 | | | 1332 | | 00 00 00 00 | | | 1333 | | 00 00 00 00 | | | 1334 | | 00 00 00 | | | 1335 | 167 | 00 00 00 06 | isutcnt | 6 | 1336 | 171 | 00 00 00 06 | isstdcnt | 6 | 1337 | 175 | 00 00 00 00 | leapcnt | 0 | 1338 | 179 | 00 00 00 07 | timecnt | 7 | 1339 | 183 | 00 00 00 06 | typecnt | 6 | 1340 | 187 | 00 00 00 14 | charcnt | 20 | 1341 | | | | | 1342 | 191 | ff ff ff ff | trans time[0] | -2334101314 | 1343 | | 74 e0 70 be | | (1896-01-13T22:31:26Z) | 1344 | 199 | ff ff ff ff | trans time[1] | -1157283000 | 1345 | | bb 05 43 48 | | (1933-04-30T12:30:00Z) | 1346 | 207 | ff ff ff ff | trans time[2] | -1155436200 | 1347 | | bb 21 71 58 | | (1933-05-21T21:30:00Z) | 1348 | 215 | ff ff ff ff | trans time[3] | -880198200 | 1349 | | cb 89 3d c8 | | (1942-02-09T12:30:00Z) | 1350 | 223 | ff ff ff ff | trans time[4] | -769395600 | 1351 | | d2 23 f4 70 | | (1945-08-14T23:00:00Z) | 1352 | 231 | ff ff ff ff | trans time[5] | -765376200 | 1353 | | d2 61 49 38 | | (1945-09-30T11:30:00Z) | 1354 | 239 | ff ff ff ff | trans time[6] | -712150200 | 1355 | | d5 8d 73 48 | | (1947-06-08T12:30:00Z) | 1356 | | | | | 1357 | 247 | 01 | trans type[0] | 1 | 1358 | 248 | 02 | trans type[1] | 2 | 1359 | 249 | 01 | trans type[2] | 1 | 1360 | 250 | 03 | trans type[3] | 3 | 1361 | 251 | 04 | trans type[4] | 4 | 1362 | 252 | 01 | trans type[5] | 1 | 1363 | 253 | 05 | trans type[6] | 5 | 1364 | | | | | 1365 | | | localtimetype[0] | | 1366 | 254 | ff ff 6c 02 | utoff | -37886 (-10:21:26) | 1367 | 258 | 00 | isdst | 0 (no) | 1368 | 259 | 00 | desigidx | 0 | 1369 | | | | | 1370 | | | localtimetype[1] | | 1371 | 260 | ff ff 6c 58 | utoff | -37800 (-10:30) | 1372 | 264 | 00 | isdst | 0 (no) | 1373 | 265 | 04 | desigidx | 4 | 1374 | | | | | 1375 | | | localtimetype[2] | | 1376 | 266 | ff ff 7a 68 | utoff | -34200 (-09:30) | 1377 | 270 | 01 | isdst | 1 (yes) | 1378 | 271 | 08 | desigidx | 8 | 1379 | | | | | 1380 | | | localtimetype[3] | | 1381 | 272 | ff ff 7a 68 | utoff | -34200 (-09:30) | 1382 | 276 | 01 | isdst | 1 (yes) | 1383 | 277 | 0c | desigidx | 12 | 1384 | | | | | 1385 | | | localtimetype[4] | | 1386 | 278 | ff ff 7a 68 | utoff | -34200 (-09:30) | 1387 | 282 | 01 | isdst | 1 (yes) | 1388 | 283 | 10 | desigidx | 16 | 1389 | | | | | 1390 | | | localtimetype[5] | | 1391 | 284 | ff ff 73 60 | utoff | -36000 (-10:00) | 1392 | 288 | 00 | isdst | 0 (no) | 1393 | 289 | 04 | desigidx | 4 | 1394 | | | | | 1395 | 290 | 4c 4d 54 00 | designations[0] | "LMT" | 1396 | 294 | 48 53 54 00 | designations[4] | "HST" | 1397 | 298 | 48 44 54 00 | designations[8] | "HDT" | 1398 | 302 | 48 57 54 00 | designations[12] | "HWT" | 1399 | 306 | 48 50 54 00 | designations[16] | "HPT" | 1400 | | | | | 1401 | 310 | 00 | standard/wall[0] | 0 (wall) | 1402 | 311 | 00 | standard/wall[1] | 0 (wall) | 1403 | 312 | 00 | standard/wall[2] | 0 (wall) | 1404 | 313 | 00 | standard/wall[3] | 0 (wall) | 1405 | 314 | 01 | standard/wall[4] | 1 (standard) | 1406 | 315 | 00 | standard/wall[5] | 0 (wall) | 1407 | | | | | 1408 | 316 | 00 | UT/local[0] | 0 (local) | 1409 | 317 | 00 | UT/local[1] | 0 (local) | 1410 | 318 | 00 | UT/local[2] | 0 (local) | 1411 | 319 | 00 | UT/local[3] | 0 (local) | 1412 | 320 | 01 | UT/local[4] | 1 (UT) | 1413 | 321 | 00 | UT/local[5] | 0 (local) | 1414 | | | | | 1415 | 322 | 0a | NL | '\n' | 1416 | 323 | 48 53 54 31 | TZ string | "HST10" | 1417 | | 30 | | | 1418 | 328 | 0a | NL | '\n' | 1419 +--------+--------------+------------------+------------------------+ 1421 To determine the local time in this time zone corresponding to 1422 1933-05-04T12:00:00Z (UNIX time = -1156939200), the following 1423 procedure would be followed: 1425 1. Find the latest time transition prior to the time of interest 1426 (trans time[1]). 1428 2. Reference the corresponding transition type (trans type[1]) to 1429 determine the local time type index (2). 1431 3. Reference the corresponding local time type (localtimetype[2]) to 1432 determine the offset from UTC (-09:30), the daylight saving 1433 indicator (1 = yes), and the index into the time zone designation 1434 strings (8). 1436 4. Look up the corresponding time zone designation string 1437 (designations[8] = "HDT"). 1439 5. Add the UTC offset to the time of interest to yield a local 1440 daylight saving time of 1933-05-04T02:30:00-09:30 (HDT). 1442 To determine the local time in this time zone corresponding to 1443 2019-01-01T00:00:00Z (UNIX time = 1546300800), the following 1444 procedure would be followed: 1446 1. Find the latest time transition prior to the time of interest 1447 (there is no such transition). 1449 2. Look up the TZ string in the footer ("HST10"), which indicates 1450 that the time zone designation is "HST" year-round, and the 1451 offset to UTC is 10:00. 1453 3. Subtract the UTC offset from the time of interest to yield a 1454 standard local time of 2018-12-31T14:00:00-10:00 (HST). 1456 B.3. Truncated Version 3 File Representing Asia/Jerusalem 1458 The following TZif file has been truncated to start on 1459 2038-01-01T00:00:00Z. 1461 In this example: 1463 o The start time value can not be represented using 32 bits, so the 1464 version 1 header contains only the required minimum data, which 1465 will be ignored by readers. 1467 o The version 3 header leverages the fact that by specifying 1468 'isutcnt' and 'isstdcnt' as zero, all transition times associated 1469 with local time types are assumed to be specified as local wall- 1470 clock time (see the definitions of UT/local indicators and 1471 standard/wall indicators in Section 3.2). 1473 +-------+------------+-----------------+----------------------------+ 1474 | File | Hexadecima | Record Name / | Field Value | 1475 | Offse | l Octets | Field Name | | 1476 | t | | | | 1477 +-------+------------+-----------------+----------------------------+ 1478 | 000 | 54 5a 69 | magic | "TZif" | 1479 | | 66 | | | 1480 | 004 | 33 | version | '3' (3) | 1481 | 005 | 00 00 00 | | | 1482 | | 00 00 00 | | | 1483 | | 00 00 00 | | | 1484 | | 00 00 00 | | | 1485 | | 00 00 00 | | | 1486 | 020 | 00 00 00 | isutcnt | 0 | 1487 | | 00 | | | 1488 | 024 | 00 00 00 | isstdcnt | 0 | 1489 | | 00 | | | 1490 | 028 | 00 00 00 | leapcnt | 0 | 1491 | | 00 | | | 1492 | 032 | 00 00 00 | timecnt | 0 | 1493 | | 00 | | | 1494 | 036 | 00 00 00 | typecnt | 1 | 1495 | | 01 | | | 1496 | 040 | 00 00 00 | charcnt | 1 | 1497 | | 01 | | | 1498 | | | | | 1499 | | | localtimetype[0 | | 1500 | | | ] | | 1501 | 044 | 00 00 00 | utoff | 0 (+00:00) | 1502 | | 00 | | | 1503 | 048 | 00 | isdst | 0 (no) | 1504 | 049 | 00 | desigidx | 0 | 1505 | | | | | 1506 | 050 | 00 | designations[0] | "" | 1507 | | | | | 1508 | 051 | 54 5a 69 | magic | "TZif" | 1509 | | 66 | | | 1510 | 055 | 33 | version | '3' (3) | 1511 | 056 | 00 00 00 | | | 1512 | | 00 00 00 | | | 1513 | | 00 00 00 | | | 1514 | | 00 00 00 | | | 1515 | | 00 00 00 | | | 1516 | 071 | 00 00 00 | isutcnt | 0 | 1517 | | 00 | | | 1518 | 075 | 00 00 00 | isstdcnt | 0 | 1519 | | 00 | | | 1520 | 079 | 00 00 00 | leapcnt | 0 | 1521 | | 00 | | | 1522 | 083 | 00 00 00 | timecnt | 1 | 1523 | | 01 | | | 1524 | 087 | 00 00 00 | typecnt | 1 | 1525 | | 01 | | | 1526 | 091 | 00 00 00 | charcnt | 4 | 1527 | | 04 | | | 1528 | | | | | 1529 | 095 | 00 00 00 | trans time[0] | 2145916800 | 1530 | | 00 7f e8 | | (2038-01-01T00:00:00Z) | 1531 | | 17 80 | | | 1532 | | | | | 1533 | 103 | 00 | trans type[0] | 0 | 1534 | | | | | 1535 | | | localtimetype[0 | | 1536 | | | ] | | 1537 | 104 | 00 00 1c | utoff | 7200 (+02:00) | 1538 | | 20 | | | 1539 | 108 | 00 | isdst | 0 (no) | 1540 | 109 | 00 | desigidx | 0 | 1541 | | | | | 1542 | 110 | 49 53 54 | designations[0] | "IST" | 1543 | | 00 | | | 1544 | | | | | 1545 | 114 | 0a | NL | '\n' | 1546 | 115 | 49 53 54 | TZ string | "IST-2IDT,M3.4.4/26,M10.5. | 1547 | | 2d 32 49 | | 0" | 1548 | | 44 54 2c | | | 1549 | | 4d 33 2e | | | 1550 | | 34 2e 34 | | | 1551 | | 2f 32 36 | | | 1552 | | 2c 4d 31 | | | 1553 | | 30 2e 35 | | | 1554 | | 2e 30 | | | 1555 | 141 | 0a | NL | '\n' | 1556 +-------+------------+-----------------+----------------------------+ 1558 Appendix C. Changes from RFC 8536 1560 o Applied erratum [Err6435]. 1562 o Addressed erratum [Err6426] and several other errors in the 1563 examples. 1565 o Clarified the all-year daylight saving time TZ string 1566 (Section 3.3.1) example and added a similar example with negative 1567 DST. 1569 o Added informational notes to Appendix B.3. 1571 o Miscellaneous editorial changes. 1573 Appendix D. Change Log 1575 This section is to be removed by RFC Editor before publication. 1577 D.1. Since RFC 8536 1579 o Applied erratum [Err6435]. 1581 o Addressed erratum [Err6426] and several other errors in the 1582 examples. 1584 o Clarified the all-year daylight saving time TZ string 1585 (Section 3.3.1) example and added a similar example with negative 1586 DST. 1588 o Added informational notes to Appendix B.3. 1590 o Miscellaneous editorial changes. 1592 o Added text obsoleting [RFC8536]. 1594 o Added Changes from RFC 8536 (Appendix C). 1596 o Added Tim Parenti as a contributor. 1598 Acknowledgments 1600 The authors would like to thank the following individuals for 1601 contributing their ideas and support for writing this specification: 1602 Michael Douglass, Ned Freed, Guy Harris, Eliot Lear, Alexey Melnikov, 1603 and Tim Parenti. 1605 Authors' Addresses 1607 Arthur David Olson 1609 Email: arthurdavidolson@gmail.com 1611 Paul Eggert 1612 University of California, Los Angeles 1614 Email: eggert@cs.ucla.edu 1616 Kenneth Murchison 1617 Fastmail US LLC 1619 Email: murch@fastmailteam.com