{
    "mode": "man",
    "parameter": "tzfile",
    "section": "5",
    "url": "https://www.chedong.com/phpMan.php/man/tzfile/5/json",
    "generated": "2026-08-14T16:59:40Z",
    "sections": {
        "NAME": {
            "content": "tzfile - timezone information\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "The  timezone information files used by tzset(3) are typically found under a directory with a\nname like /usr/share/zoneinfo.  These files use the format described in  Internet  RFC  8536.\nEach  file is a sequence of 8-bit bytes.  In a file, a binary integer is represented by a se‐\nquence of one or more bytes in network order (bigendian, or high-order byte first), with  all\nbits  significant,  a  signed  binary  integer  is  represented using two's complement, and a\nboolean is represented by a one-byte binary integer that is either 0  (false)  or  1  (true).\nThe format begins with a 44-byte header containing the following fields:\n\n•  The  magic four-byte ASCII sequence “TZif” identifies the file as a timezone information\nfile.\n\n•  A byte identifying the version of the file's format (as of 2021, either  an  ASCII  NUL,\n“2”, “3”, or “4”).\n\n•  Fifteen bytes containing zeros reserved for future use.\n\n•  Six four-byte integer values, in the following order:\n\ntzhttisutcnt\nThe number of UT/local indicators stored in the file.  (UT is Universal Time.)\n\ntzhttisstdcnt\nThe number of standard/wall indicators stored in the file.\n\ntzhleapcnt\nThe number of leap seconds for which data entries are stored in the file.\n\ntzhtimecnt\nThe number of transition times for which data entries are stored in the file.\n\ntzhtypecnt\nThe number of local time types for which data entries are stored in the file (must not\nbe zero).\n\ntzhcharcnt\nThe number of bytes of time zone abbreviation strings stored in the file.\n\nThe above header is followed by the following fields, whose lengths depend on the contents of\nthe header:\n\n•  tzhtimecnt four-byte signed integer values sorted in ascending order.  These values are\nwritten  in  network  byte  order.   Each  is  used as a transition time (as returned by\ntime(2)) at which the rules for computing local time change.\n\n•  tzhtimecnt one-byte unsigned integer values; each one but the last tells which  of  the\ndifferent  types  of  local time types described in the file is associated with the time\nperiod starting with the same-indexed transition time and continuing up to but  not  in‐\ncluding  the  next transition time.  (The last time type is present only for consistency\nchecking with the POSIX.1-2017-style TZ string described below.)  These values serve  as\nindices into the next field.\n\n•  tzhtypecnt ttinfo entries, each defined as follows:\n\nstruct ttinfo {\nint32t       ttutoff;\nunsigned char ttisdst;\nunsigned char ttdesigidx;\n};\n\nEach  structure  is written as a four-byte signed integer value for ttutoff, in network\nbyte order, followed by a one-byte boolean for ttisdst and a one-byte value for  ttde‐\nsigidx.   In  each  structure,  ttutoff  gives the number of seconds to be added to UT,\nttisdst tells whether tmisdst should be set by localtime(3) and ttdesigidx serves  as\nan  index  into the array of time zone abbreviation bytes that follow the ttinfo entries\nin the file; if the designated string is \"-00\", the ttinfo entry is a placeholder  indi‐\ncating  that local time is unspecified.  The ttutoff value is never equal to -231, to\nlet 32-bit clients negate it without overflow.  Also, in realistic applications ttutoff\nis in the range [-89999, 93599] (i.e., more than -25 hours and less than 26 hours); this\nallows easy support by implementations that already  support  the  POSIX-required  range\n[-24:59:59, 25:59:59].\n\n•  tzhcharcnt  bytes that represent time zone designations, which are null-terminated byte\nstrings, each indexed by the ttdesigidx values mentioned above.  The byte  strings  can\noverlap  if  one  is a suffix of the other.  The encoding of these strings is not speci‐\nfied.\n\n•  tzhleapcnt pairs of four-byte values, written in network byte order; the first value of\neach pair gives the nonnegative time (as returned by time(2)) at which a leap second oc‐\ncurs or at which the leap second table expires; the second is a signed integer  specify‐\ning  the  correction, which is the total number of leap seconds to be applied during the\ntime period starting at the given time.  The pairs of values are sorted in strictly  as‐\ncending  order by time.  Each pair denotes one leap second, either positive or negative,\nexcept that if the last pair has the same correction as the previous one, the last  pair\ndenotes  the  leap  second table's expiration time.  Each leap second is at the end of a\nUTC calendar month.  The first leap second has a nonnegative occurrence time, and  is  a\npositive  leap second if and only if its correction is positive; the correction for each\nleap second after the first differs from the previous leap second by either 1 for a pos‐\nitive leap second, or -1 for a negative leap second.  If the leap second table is empty,\nthe leap-second correction is zero for all timestamps; otherwise, for timestamps  before\nthe  first  occurrence time, the leap-second correction is zero if the first pair's cor‐\nrection is 1 or -1, and is unspecified otherwise (which can happen only in  files  trun‐\ncated at the start).\n\n•  tzhttisstdcnt  standard/wall  indicators,  each stored as a one-byte boolean; they tell\nwhether the transition times associated with local time types were specified as standard\ntime or local (wall clock) time.\n\n•  tzhttisutcnt UT/local indicators, each stored as a one-byte boolean; they tell  whether\nthe  transition  times  associated  with  local time types were specified as UT or local\ntime.  If a UT/local indicator is set, the corresponding  standard/wall  indicator  must\nalso be set.\n\nThe  standard/wall and UT/local indicators were designed for transforming a TZif file's tran‐\nsition  times  into  transitions  appropriate  for  another  time  zone   specified   via   a\nPOSIX.1-2017-style TZ string that lacks rules.  For example, when TZ=\"EET-2EEST\" and there is\nno  TZif  file  \"EET-2EEST\", the idea was to adapt the transition times from a TZif file with\nthe well-known name \"posixrules\" that is present only for this purpose and is a copy  of  the\nfile \"Europe/Brussels\", a file with a different UT offset.  POSIX does not specify this obso‐\nlete  transformational  behavior, the default rules are installation-dependent, and no imple‐\nmentation is known to support this feature for timestamps past 2037, so users desiring  (say)\nGreek  time should instead specify TZ=\"Europe/Athens\" for better historical coverage, falling\nback on TZ=\"EET-2EEST,M3.5.0/3,M10.5.0/4\" if POSIX conformance is required  and  older  time‐\nstamps need not be handled accurately.\n\nThe  localtime(3)  function  normally  uses  the first ttinfo structure in the file if either\ntzhtimecnt is zero or the time argument is less than the first transition time  recorded  in\nthe file.\n",
            "subsections": []
        },
        "NOTES": {
            "content": "This manual page documents <tzfile.h> in the glibc source archive, see timezone/tzfile.h.\n\nIt  seems  that timezone uses tzfile internally, but glibc refuses to expose it to userspace.\nThis is most likely because the standardised functions are more useful and portable, and  ac‐\ntually documented by glibc.  It may only be in glibc just to support the non-glibc-maintained\ntimezone data (which is maintained by some other entity).\n",
            "subsections": [
                {
                    "name": "Version 2 format",
                    "content": "For  version-2-format  timezone  files,  the  above  header and data are followed by a second\nheader and data, identical in format except that eight bytes are  used  for  each  transition\ntime  or  leap second time.  (Leap second counts remain four bytes.)  After the second header\nand data comes a newline-enclosed string in the style of the contents of  a  POSIX.1-2017  TZ\nenvironment  variable,  for use in handling instants after the last transition time stored in\nthe file or for all instants if the file has no transitions.  The TZ string is  empty  (i.e.,\nnothing  between  the newlines) if there is no POSIX.1-2017-style representation for such in‐\nstants.  If nonempty, the TZ string must agree with the local time type after the last  tran‐\nsition   time   if   present   in   the  eight-byte  data;  for  example,  given  the  string\n“WET0WEST,M3.5.0/1,M10.5.0” then if a last transition time is in July, the transition's local\ntime type must specify a daylight-saving time abbreviated “WEST” that is one hour east of UT.\nAlso, if there is at least one transition, time type 0 is associated  with  the  time  period\nfrom the indefinite past up to but not including the earliest transition time.\n"
                },
                {
                    "name": "Version 3 format",
                    "content": "For  version-3-format  timezone  files,  the  TZ  string  may use two minor extensions to the\nPOSIX.1-2017 TZ format, as described in newtzset(3).  First, the hours part of its transition\ntimes may be signed and range from -167 through 167 instead of  the  POSIX-required  unsigned\nvalues  from 0 through 24.  Second, DST is in effect all year if it starts January 1 at 00:00\nand ends December 31 at 24:00 plus the difference between daylight saving and standard time.\n"
                },
                {
                    "name": "Version 4 format",
                    "content": "For version-4-format TZif files, the first leap second record can have a correction  that  is\nneither  +1  nor  -1, to represent truncation of the TZif file at the start.  Also, if two or\nmore leap second transitions are present and the last entry's correction equals the  previous\none, the last entry denotes the expiration of the leap second table instead of a leap second;\ntimestamps  after this expiration are unreliable in that future releases will likely add leap\nsecond entries after the expiration, and the added leap seconds will change how  post-expira‐\ntion timestamps are treated.\n"
                },
                {
                    "name": "Interoperability considerations",
                    "content": "Future changes to the format may append more data.\n\nVersion  1  files  are considered a legacy format and should not be generated, as they do not\nsupport transition times after the year 2038.  Readers that understand only  Version  1  must\nignore any data that extends beyond the calculated end of the version 1 data block.\n\nOther  than  version  1, writers should generate the lowest version number needed by a file's\ndata.  For example, a writer should generate a version 4 file only if its leap  second  table\neither  expires  or is truncated at the start.  Likewise, a writer not generating a version 4\nfile should generate a version 3 file only if TZ string extensions  are  necessary  to  accu‐\nrately model transition times.\n\nThe  sequence of time changes defined by the version 1 header and data block should be a con‐\ntiguous sub-sequence of the time changes defined by the version 2+ header and data block, and\nby the footer.  This guideline helps obsolescent version 1 readers agree with current readers\nabout timestamps within the contiguous sub-sequence.  It also lets writers not supporting ob‐\nsolescent readers use a tzhtimecnt of zero in the version 1 data block to save space.\n\nWhen a TZif file contains a leap second table expiration time,  TZif  readers  should  either\nrefuse  to  process post-expiration timestamps, or process them as if the expiration time did\nnot exist (possibly with an error indication).\n\nTime zone designations should consist of at least three (3) and no more than  six  (6)  ASCII\ncharacters from the set of alphanumerics, “-”, and “+”.  This is for compatibility with POSIX\nrequirements for time zone abbreviations.\n\nWhen  reading a version 2 or higher file, readers should ignore the version 1 header and data\nblock except for the purpose of skipping over them.\n\nReaders should calculate the total lengths of the headers and data blocks and check that they\nall fit within the actual file size, as part of a validity check for the file.\n\nWhen a positive leap second occurs, readers should append an extra second to the local minute\ncontaining the second just before the leap second.  If this occurs when the UTC offset is not\na multiple of 60 seconds, the leap second occurs earlier than the last second  of  the  local\nminute  and the minute's remaining local seconds are numbered through 60 instead of the usual\n59; the UTC offset is unaffected.\n"
                },
                {
                    "name": "Common interoperability issues",
                    "content": "This section documents common problems in reading or writing TZif files.  Most of  these  are\nproblems in generating TZif files for use by older readers.  The goals of this section are:\n\n•  to  help  TZif  writers  output  files that avoid common pitfalls in older or buggy TZif\nreaders,\n\n•  to help TZif readers avoid common pitfalls when reading files generated by  future  TZif\nwriters, and\n\n•  to  help  any future specification authors see what sort of problems arise when the TZif\nformat is changed.\n\nWhen new versions of the TZif format have been defined, a design goal has been that a  reader\ncan  successfully  use  a TZif file even if the file is of a later TZif version than what the\nreader was designed for.  When complete compatibility was not achieved, an attempt  was  made\nto  limit  glitches to rarely used timestamps and allow simple partial workarounds in writers\ndesigned to generate new-version data useful even for older-version  readers.   This  section\nattempts to document these compatibility issues and workarounds, as well as to document other\ncommon bugs in readers.\n\nInteroperability problems with TZif include the following:\n\n•  Some  readers examine only version 1 data.  As a partial workaround, a writer can output\nas much version 1 data as possible.  However, a reader should ignore version 1 data, and\nshould use version 2+ data even if the reader's native timestamps have only 32 bits.\n\n•  Some readers designed for version 2 might mishandle timestamps  after  a  version  3  or\nhigher  file's  last transition, because they cannot parse extensions to POSIX.1-2017 in\nthe TZ-like string.  As a partial workaround, a writer can output more transitions  than\nnecessary, so that only far-future timestamps are mishandled by version 2 readers.\n\n•  Some  readers  designed for version 2 do not support permanent daylight saving time with\ntransitions after 24:00 – e.g., a TZ  string  “EST5EDT,0/0,J365/25”  denoting  permanent\nEastern Daylight Time (-04).  As a workaround, a writer can substitute standard time for\ntwo  time  zones  east,  e.g.,  “XXX3EDT4,0/0,J365/23” for a time zone with a never-used\nstandard time (XXX, -03) and negative daylight saving time (EDT, -04) all year.   Alter‐\nnatively,  as  a  partial  workaround a writer can substitute standard time for the next\ntime zone east – e.g., “AST4” for permanent Atlantic Standard Time (-04).\n\n•  Some readers designed for version 2 or 3, and that require  strict  conformance  to  RFC\n8536, reject version 4 files whose leap second tables are truncated at the start or that\nend in expiration times.\n\n•  Some readers ignore the footer, and instead predict future timestamps from the time type\nof  the  last transition.  As a partial workaround, a writer can output more transitions\nthan necessary.\n\n•  Some readers do not use time type 0 for timestamps before the first transition, in  that\nthey  infer a time type using a heuristic that does not always select time type 0.  As a\npartial workaround, a writer can output a dummy (no-op) first  transition  at  an  early\ntime.\n\n•  Some  readers  mishandle timestamps before the first transition that has a timestamp not\nless than -231.  Readers that support only 32-bit timestamps are  likely  to  be  more\nprone  to  this  problem, for example, when they process 64-bit transitions only some of\nwhich are representable in 32 bits.  As a partial workaround,  a  writer  can  output  a\ndummy transition at timestamp -231.\n\n•  Some  readers  mishandle  a  transition if its timestamp has the minimum possible signed\n64-bit value.  Timestamps less than -259 are not recommended.\n\n•  Some readers mishandle TZ strings that contain “<” or “>”.  As a partial  workaround,  a\nwriter can avoid using “<” or “>” for time zone abbreviations containing only alphabetic\ncharacters.\n\n•  Many readers mishandle time zone abbreviations that contain non-ASCII characters.  These\ncharacters are not recommended.\n\n•  Some  readers  may  mishandle  time zone abbreviations that contain fewer than 3 or more\nthan 6 characters, or that contain ASCII characters other than alphanumerics,  “-”,  and\n“+”.  These abbreviations are not recommended.\n\n•  Some  readers mishandle TZif files that specify daylight-saving time UT offsets that are\nless than the UT offsets for the corresponding standard time.  These readers do not sup‐\nport  locations  like  Ireland,  which  uses   the   equivalent   of   the   TZ   string\n“IST-1GMT0,M10.5.0,M3.5.0/1”,  observing standard time (IST, +01) in summer and daylight\nsaving time (GMT, +00) in winter.  As a partial workaround, a writer can output data for\nthe equivalent of the TZ string “GMT0IST,M3.5.0/1,M10.5.0”, thus swapping  standard  and\ndaylight  saving  time.   Although  this workaround misidentifies which part of the year\nuses daylight saving time, it records UT offsets and time zone abbreviations correctly.\n\n•  Some readers generate ambiguous timestamps for positive leap seconds that occur when the\nUTC offset is not a multiple of 60 seconds.  For example, in a timezone with UTC  offset\n+01:23:45 and with a positive leap second 78796801 (1972-06-30 23:59:60 UTC), some read‐\ners  will  map both 78796800 and 78796801 to 01:23:45 local time the next day instead of\nmapping the latter to 01:23:46, and they will map 78796815 to  01:23:59  instead  of  to\n01:23:60.   This  has not yet been a practical problem, since no civil authority has ob‐\nserved such UTC offsets since leap seconds were introduced in 1972.\n\nSome interoperability problems are reader bugs that are listed here mostly as warnings to de‐\nvelopers of readers.\n\n•  Some readers do not support negative timestamps.  Developers of distributed applications\nshould keep this in mind if they need to deal with pre-1970 data.\n\n•  Some readers mishandle timestamps before the first transition  that  has  a  nonnegative\ntimestamp.   Readers that do not support negative timestamps are likely to be more prone\nto this problem.\n\n•  Some readers mishandle time zone abbreviations like “-08” that contain “+”, “-”, or dig‐\nits.\n\n•  Some readers mishandle UT offsets that are out of the traditional range of  -12  through\n+12 hours, and so do not support locations like Kiritimati that are outside this range.\n\n•  Some readers mishandle UT offsets in the range [-3599, -1] seconds from UT, because they\ninteger-divide the offset by 3600 to get 0 and then display the hour part as “+00”.\n\n•  Some readers mishandle UT offsets that are not a multiple of one hour, or of 15 minutes,\nor of 1 minute.\n"
                }
            ]
        },
        "SEE ALSO": {
            "content": "time(2), localtime(3), tzset(3), tzselect(8), zdump(8), zic(8).\n\nOlson A, Eggert P, Murchison K. The Time Zone Information Format (TZif).  2019 Feb.  \u001b]8;;https://datatracker.ietf.org/doc/html/rfc8536\u001b\\Internet\nRFC 8536\u001b]8;;\u001b\\ \u001b]8;;https://doi.org/10.17487/RFC8536\u001b\\doi:10.17487/RFC8536\u001b]8;;\u001b\\.\n\nTime Zone Database                                                                         tzfile(5)",
            "subsections": []
        }
    },
    "summary": "tzfile - timezone information",
    "flags": [],
    "examples": [],
    "see_also": [
        {
            "name": "time",
            "section": "2",
            "url": "https://www.chedong.com/phpMan.php/man/time/2/json"
        },
        {
            "name": "localtime",
            "section": "3",
            "url": "https://www.chedong.com/phpMan.php/man/localtime/3/json"
        },
        {
            "name": "tzset",
            "section": "3",
            "url": "https://www.chedong.com/phpMan.php/man/tzset/3/json"
        },
        {
            "name": "tzselect",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/tzselect/8/json"
        },
        {
            "name": "zdump",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/zdump/8/json"
        },
        {
            "name": "zic",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/zic/8/json"
        }
    ]
}