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