1.\" $NetBSD: tzfile.5,v 1.37 2025/01/23 22:44:22 christos Exp $ 2.\" 3.\" @(#)tzfile.5 8.3 4.\" This file is in the public domain, so clarified as of 5.\" 2009-05-17 by Arthur David Olson. 6.Dd September 10, 2024 7.Dt TZFILE 5 8.Os 9.Sh NAME 10.Nm tzfile 11.Nd time zone information 12.Sh DESCRIPTION 13The timezone information files used by 14.Xr tzset 3 15are typically found under a directory with a name like 16.Pa /usr/share/zoneinfo . 17These files use the format described in Internet 18.Rs 19.%R RFC 9536 20.Re 21Each file is a sequence of 8-bit bytes. 22In a file, a binary integer is represented by a sequence of one or 23more bytes in network order (bigendian, or high-order byte first), 24with all bits significant, 25a signed binary integer is represented using two's complement, 26and a boolean is represented by a one-byte binary integer that is 27either 28.Dv 0 29(false) or 30.Dv 1 31(true). 32.Bl -bullet 33.It 34The magic four-byte ASCII sequence begin with the magic characters 35.Dq TZif . 36identifies the file as a timezone information file. 37.It 38A byte identifying the version of the file's format 39(as of 2021, either an ASCII 40.Dv NUL , 41or 42.Dq 3 , 43or 44.Dq 4 ). 45.It 46Fifteen bytes containing zeros reserved for future use. 47.It 48Six four-byte integer values, in the following order: 49.Bl -inset 50.It Va tzh_ttisutcnt 51The number of UT/local indicators stored in the file. 52(UT is Universal Time.) 53.It Va tzh_ttisstdcnt 54The number of standard/wall indicators stored in the file. 55.It Va tzh_leapcnt 56The number of leap seconds for which data entries are stored in the file. 57.It Va tzh_timecnt 58The number of transition times for which data entries are stored 59in the file. 60.It Va tzh_typecnt 61The number of local time types for which data entries are stored 62in the file (must not be zero). 63.It Va tzh_charcnt 64The number of bytes of timezone abbreviation strings 65stored in the file. 66.El 67.It 68The above header is followed by the following fields, whose lengths 69depend on the contents of the header: 70.Bl -inset 71.It Va tzh_timecnt 72four-byte signed integer values sorted in ascending order. 73These values are written in 74These values are written in standard byte order. 75Each is used as a transition time (as returned by 76.Xr time 3 ) 77at which the rules for computing local time change. 78.It Va tzh_timecnt 79one-byte unsigned integer values; 80each one but the last tells which of the different types of local time types 81described in the file is associated with the time period 82starting with the same-indexed transition time 83and continuing up to but not including the next transition time. 84(The last time type is present only for consistency checking with the 85proleptic TZ string described below.) 86These values serve as indices into the next field. 87.It Va tzh_typecnt 88.Va ttinfo 89entries, each defined as follows: 90.Bd -literal 91struct ttinfo { 92 int32_t tt_uttoff; 93 unsigned char tt_isdst; 94 unsigned char tt_desigind; 95}; 96.Ed 97.Pp 98Each structure is written as a four-byte signed integer value for 99.Va tt_gmtoff 100in a network byte order, followed by a one-byte value for 101.Va tt_isdst 102and a one-byte value for 103.Va tt_desigidx . 104In each structure, 105.Va tt_gmtoff 106gives the number of seconds to be added to UT, 107.Va tt_isdst 108tells whether 109.Va tm_isdst 110should be set by 111.Xr localtime 3 112and 113.Va tt_desigidx 114serves as an index into the array of timezone abbreviation bytes 115that follow the 116.Va ttinfo 117structure(s) in the file. 118entries in the file; if the designated string is 119.Dq \e*-00 , 120the 121.Va ttinfo 122entry is a placeholder indicating that local time is unspecified. 123The 124.Va tt_utoff 125+value is never equal to \-2**31, 126to let 32-bit clients negate it without overflow. 127Also, in realistic applications 128.Va tt_utoff 129is in the range [\-89999, 93599] 130(i.e., more than \-25 hours and less than 26 131hours); this allows easy support by implementations that 132already support the POSIX-required range 133.Dv [ \-24:59:59 , 25:59:59 ] . 134.It Va tzh_charcnt 135bytes that represent time zone designations, 136which are null-terminated byte strings, each indexed by the 137.It Va tt_desigidx 138values mentioned above. 139The byte strings can overlap if one is a suffix of the other. 140The encoding of these strings is not specified. 141.IP * 142.It Va tzh_leapcnt 143pairs of four-byte values, written in network byte order; 144the first value of each pair gives the time 145(as returned by 146.Xr time 3 ) 147at which a leap second occurs or at which the leap second table expires; 148the second is a signed integer specifying the correction, which is the 149.Em total 150number of leap seconds to be applied during the time period 151starting at the given time. 152The pairs of values are sorted in strictly ascending order by time. 153Each pair denotes one leap second, either positive or negative, 154except that if the last pair has the same correction as the previous one, 155the last pair denotes the leap second table's expiration time. 156Each leap second is at the end of a UTC calendar month. 157The first leap second has a non-negative occurrence time, 158and is a positive leap second if and only if its correction is positive; 159the correction for each leap second after the first differs 160from the previous leap second by either 161.Dv 1 162for a positive leap second, or 163.Dv \-1 164for a negative leap second. 165If the leap second table is empty, the leap-second correction is zero 166for all timestamps; 167otherwise, for timestamps before the first occurrence time, 168the leap-second correction is zero if the first pair's correction is 169.Dv 1 170or 171.Dv \-1 , 172and is unspecified otherwise (which can happen only in files 173truncated at the start). 174.It Va tzh_ttisstdcnt 175standard/wall indicators, each stored as a one-byte boolean; 176they tell whether the transition times associated with local time types 177were specified as standard time or local (wall clock) time. 178.It Va tzh_ttisutcnt 179UT/local indicators, each stored as a one-byte boolean; 180they tell whether the transition times associated with local time types 181were specified as UT or local time. 182If a UT/local indicator is set, the corresponding standard/wall indicator 183must also be set. 184.Pp 185The standard/wall and UT/local indicators were designed for 186transforming a TZif file's transition times into transitions appropriate 187for another time zone specified via 188a proleptic TZ string that lacks rules. 189For example, when 190.Dv TZ="EET\*-2EEST" 191and there is no TZif file 192.Dq EET\*-2EEST , 193the idea was to adapt the transition times from a TZif file with the 194well-known name "posixrules" that is present only for this purpose and 195is a copy of the file 196.Dq Europe/Brussels , 197a file with a different UT offset. 198POSIX does not specify the details of this obsolete transformational behavior, 199the default rules are installation-dependent, and no implementation 200is known to support this feature for timestamps past 201.Dv 2037 , 202so users desiring (say) Greek time should instead specify 203.Dv TZ="Europe/Athens" 204for better historical coverage, falling back on 205.Dv TZ="EET\*-2EEST,M3.5.0/3,M10.5.0/4" 206if POSIX conformance is required 207and older timestamps need not be handled accurately. 208.Pp 209The 210.Xr localtime 3 211function normally uses the first 212.Fa ttinfo 213structure in the file 214if either 215.Va tzh_timecnt 216is zero or the time argument is less than the first transition time recorded 217in the file. 218.El 219.El 220.Ss Version 2 format 221For version-2-format timezone files, 222the above header and data are followed by a second header and data, 223identical in format except that 224eight bytes are used for each transition time or leap second time. 225(Leap second counts remain four bytes.) 226After the second header and data comes a newline-enclosed string 227in the style of the contents of a proleptic TZ, 228for use in handling instants 229after the last transition time stored in the file 230or for all instants if the file has no transitions. 231The TZ string is empty (i.e., nothing between the newlines) 232if there is no proleptic representation for such instants. 233If non-empty, the TZ string must agree with the local time 234type after the last transition time if present in the eight-byte data; 235for example, given the string 236.Dq WET0WEST,M3.5.0/1,M10.5.0 237then if a last transition time is in July, the transition's local time 238type must specify a daylight-saving time abbreviated 239.Dq WEST 240that is one hour east of UT. 241Also, if there is at least one transition, time type 0 is associated 242with the time period from the indefinite past up to but not including 243the earliest transition time. 244.Ss Version 3 format 245For version-3-format timezone files, a TZ string (see 246.Xr tzset 3 247may use the following POSIX.1-2024 extensions to POSIX.1-2017: 248First, as in TZ="<\*-02>2<\*-01>,M3.5.0/\*-1,M10.5.0/0", 249the hours part of its transition times may be signed and range from 250\-167 through 167 instead of being limited to unsigned values 251from 0 through 24. 252Second, as in TZ="XXX3EDT4,0/0,J365/23", DST is in effect all year if it starts 253January 1 at 00:00 and ends December 31 at 24:00 plus the difference 254between daylight saving and standard time. 255.Ss Version 4 format 256For version-4-format TZif files, 257the first leap second record can have a correction that is neither 258.Dv +1 259nor 260.Dv \-1 , 261to represent truncation of the TZif file at the start. 262Also, if two or more leap second transitions are present and the last 263entry's correction equals the previous one, the last entry 264denotes the expiration of the leap second table instead of a leap second; 265timestamps after this expiration are unreliable in that future 266releases will likely add leap second entries after the expiration, and 267the added leap seconds will change how post-expiration timestamps are treated. 268.Ss Interoperability considerations 269.Pp 270Version 1 files are considered a legacy format and 271should not be generated, as they do not support transition 272times after the year 2038. 273Readers that understand only Version 1 must ignore 274any data that extends beyond the calculated end of the version 2751 data block. 276.PP 277Other than version 1, writers should generate 278the lowest version number needed by a file's data. 279For example, a writer should generate a version 4 file 280only if its leap second table either expires or is truncated at the start. 281Likewise, a writer not generating a version 4 file 282should generate a version 3 file only if 283TZ string extensions are necessary to accurately 284model transition times. 285.Pp 286The sequence of time changes defined by the version 1 287header and data block should be a contiguous sub-sequence 288of the time changes defined by the version 2+ header and data 289block, and by the footer. 290This guideline helps obsolescent version 1 readers 291agree with current readers about timestamps within the 292contiguous sub-sequence. It also lets writers not 293supporting obsolescent readers use a 294.Dv tzh_timecnt 295of zero 296in the version 1 data block to save space. 297.Pp 298When a TZif file contains a leap second table expiration 299time, TZif readers should either refuse to process 300post-expiration timestamps, or process them as if the expiration 301time did not exist (possibly with an error indication). 302.Pp 303Time zone designations should consist of at least three (3) 304and no more than six (6) ASCII characters from the set of 305alphanumerics, 306.Dq \&- , 307and 308.Dq + . 309This is for compatibility with POSIX requirements for 310time zone abbreviations. 311.Pp 312When reading a version 2 or higher file, readers 313should ignore the version 1 header and data block except for 314the purpose of skipping over them. 315.Pp 316Readers should calculate the total lengths of the 317headers and data blocks and check that they all fit within 318the actual file size, as part of a validity check for the file. 319.Pp 320When a positive leap second occurs, readers should append an extra 321second to the local minute containing the second just before the leap 322second. If this occurs when the UTC offset is not a multiple of 60 323seconds, the leap second occurs earlier than the last second of the 324local minute and the minute's remaining local seconds are numbered 325through 60 instead of the usual 59; the UTC offset is unaffected. 326.Ss Common interoperability issues 327This section documents common problems in reading or writing TZif files. 328Most of these are problems in generating TZif files for use by 329older readers. 330The goals of this section are to help: 331.Bl -bullet 332.It 333TZif writers output files that avoid common 334pitfalls in older or buggy TZif readers, 335.It 336TZif readers avoid common pitfalls when reading 337files generated by future TZif writers, and 338.It 339any future specification authors see what sort of 340problems arise when the TZif format is changed. 341.El 342.Pp 343+When new versions of the TZif format have been defined, a 344design goal has been that a reader can successfully use a TZif 345file even if the file is of a later TZif version than what the 346reader was designed for. 347When complete compatibility was not achieved, an attempt was 348made to limit glitches to rarely used timestamps and allow 349simple partial workarounds in writers designed to generate 350newer-version data useful even for older-version readers. 351This section attempts to document these compatibility issues and 352workarounds, as well as to document other common bugs in 353readers. 354.Pp 355Interoperability problems with TZif include the following: 356.Bl -bullet 357.It 358Some stripped-down readers ignore everything but the footer, 359and use its proleptic TZ string to calculate all timestamps. 360Although this approach often works for current and future timestamps, 361it obviously has problems with past timestamps, 362and even for current timestamps it can fail for settings like 363TZ="Africa/Casablanca". 364This corresponds to a TZif file 365containing explicit transitions through the year 2087, 366followed by a footer containing the TZ string 367.Dq <+01>\*-1 , 368which should be used only for timestamps after the last 369explicit transition. 370.It 371Some readers examine only version 1 data. 372As a partial workaround, a writer can output as much version 1 373data as possible. 374However, a reader should ignore version 1 data, and should use 375version 2+ data even if the reader's native timestamps have only 37632 bits. 377.It 378Some readers designed for version 2 might mishandle 379timestamps after a version 3 or higher file's last transition, because 380they cannot parse the POSIX.1-2024 extensions to POSIX.1-2017 381in the proleptic TZ string. 382As a partial workaround, a writer can output more transitions 383than necessary, so that only far-future timestamps are 384mishandled by version 2 readers. 385.It 386Some readers designed for version 2 do not support 387permanent daylight saving time, e.g., a TZ string 388permanent daylight saving time with transitions after 24:00 389\(en e.g., a TZ string 390.Dq EST5EDT,0/0,J365/25 391denoting permanent Eastern Daylight Time 392(\-04). 393As a workaround, a writer can substitute standard time 394for two time zones east, e.g., 395.Dq XXX3EDT4,0/0,J365/23 396for a time zone with a never-used standard time (XXX, \-03) 397and negative daylight saving time (EDT, \-04) all year. 398Alternatively, 399as a partial workaround a writer can substitute standard time 400for the next time zone east \(en e.g., 401.Dq AST4 402for permanent 403Atlantic Standard Time (\-04). 404.It 405Some readers designed for version 2 or 3 and that require strict 406conformance to RFC 9536 reject version 4 files whose leap second 407tables are truncated at the start or end in expiration times. 408.It 409Some readers ignore the footer, and instead predict future 410timestamps from the time type of the last transition. 411As a partial workaround, a writer can output more transitions 412than necessary. 413.It 414Some readers do not use time type 0 for timestamps before 415the first transition, in that they infer a time type using a 416heuristic that does not always select time type 0. 417As a partial workaround, a writer can output a dummy (no-op) 418first transition at an early time. 419.It 420Some readers mishandle timestamps before the first 421transition that has a timestamp that is not less than -2**31. 422Readers that support only 32-bit timestamps are likely to be 423more prone to this problem, for example, when they process 42464-bit transitions only some of which are representable in 32 425bits. 426As a partial workaround, a writer can output a dummy 427transition at timestamp \&-2**31. 428.It 429Some readers mishandle a transition if its timestamp has 430the minimum possible signed 64-bit value. 431Timestamps less than \&-2**59 are not recommended. 432.It 433Some readers mishandle proleptic TZ strings that 434contain 435.Dq < 436or 437.Dq > . 438As a partial workaround, a writer can avoid using 439.Dq < 440or 441.Dq > 442for time zone abbreviations containing only alphabetic 443characters. 444.Pp 445Many readers mishandle time zone abbreviations that contain 446non-ASCII characters. 447These characters are not recommended. 448.Pp 449Some readers may mishandle time zone abbreviations that 450contain fewer than 3 or more than 6 characters or that 451contain ASCII characters other than alphanumerics, 452.Dq \&- . 453and 454.Dq + . 455These abbreviations are not recommended. 456.It 457Some readers mishandle TZif files that specify 458daylight-saving time UT offsets that are less than the UT 459offsets for the corresponding standard time. 460These readers do not support locations like Ireland, which 461uses the equivalent of the TZ string 462.Dq IST\&-1GMT0,M10.5.0,M3.5.0/1 , 463observing standard time 464(IST, +01) in summer and daylight saving time (GMT, +00) in winter. 465As a partial workaround, a writer can output data for the 466equivalent of the TZ string 467.Dq GMT0IST,M3.5.0/1,M10.5.0 , 468thus swapping standard and daylight saving time. 469Although this workaround misidentifies which part of the year 470uses daylight saving time, it records UT offsets and time zone 471abbreviations correctly. 472.It 473Some readers generate ambiguous timestamps for positive leap seconds 474that occur when the UTC offset is not a multiple of 60 seconds. 475For example, with UTC offset +01:23:45 and with 476a positive leap second 78796801 (1972-06-30 23:59:60 UTC), some readers will 477map both 78796800 and 78796801 to 01:23:45 local time the next day 478instead of mapping the latter to 01:23:46, and they will map 78796815 to 47901:23:59 instead of to 01:23:60. 480This has not yet been a practical problem, since no civil authority 481has observed such UTC offsets since leap seconds were 482introduced in 1972. 483.El 484.Pp 485Some interoperability problems are reader bugs that 486are listed here mostly as warnings to developers of readers. 487.Bl -bullet 488.It 489Some readers do not support negative timestamps. 490Developers of distributed applications should keep this 491in mind if they need to deal with pre-1970 data. 492.It 493Some readers mishandle timestamps before the first 494transition that has a non-negative timestamp. 495Readers that do not support negative timestamps are likely to 496be more prone to this problem. 497.It 498+Some readers mishandle time zone abbreviations like 499.Dq \&-08 500that contain 501.Dq + , 502.Dq \&- , 503or digits. 504.It 505Some readers mishandle UT offsets that are out of the 506traditional range of \*-12 through +12 hours, and so do not 507support locations like Kiritimati that are outside this 508range. 509.It 510Some readers mishandle UT offsets in the range [\*-3599, \*-1] 511seconds from UT because they integer-divide the offset by 5123600 to get 0 and then display the hour part as 513.Dq +00 . 514.It 515Some readers mishandle UT offsets that are not a multiple 516of one hour, or of 15 minutes, or of 1 minute. 517Future changes to the format may append more data. 518.El 519.Sh SEE ALSO 520.Xr ctime 3 , 521.Xr localtime 3 , 522.Xr time 3 , 523.Xr tzset 3 , 524.Xr zdump 8 , 525.Xr zic 8 . 526.Rs 527.%A Olson A, Eggert P, Murchison K. 528.%T The Time Zone Information Format (TZif). 529.%D October 2024. 530%U https://\:www.rfc-editor.org/\:rfc/\:rfc9636 531%U https://doi.org/10.17487/RFC9536 532%R RFC 9536 533.Re 534