{
    "mode": "man",
    "parameter": "tzfile",
    "section": "5",
    "url": "https://www.chedong.com/phpMan.php/man/tzfile/5/json",
    "generated": "2026-05-30T07:08:33Z",
    "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 bool‐\nean is represented by a one-byte binary integer that is either 0 (false) or  1  (true).   The\nformat 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 2017, either an  ASCII  NUL,  or\n“2”, or “3”).\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\nnot be 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  time(2))\nat 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 dif‐\nferent types of local time types described in the file is associated with the  time  period\nstarting  with  the same-indexed transition time and continuing up to but not including the\nnext transition time.  (The last time type is present only for  consistency  checking  with\nthe  POSIX-style  TZ  string described below.)  These values serve as indices into the next\nfield.\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 byte\norder,  followed  by  a one-byte boolean for ttisdst and a one-byte value for ttdesigidx.\nIn each structure, ttutoff gives the number of seconds to be added to UT,  ttisdst  tells\nwhether  tmisdst should be set by localtime(3) and ttdesigidx serves as an index into the\narray of time zone abbreviation bytes that follow the ttinfo structure(s) in the file.  The\nttutoff  value is never equal to -231, to let 32-bit clients negate it without overflow.\nAlso, in realistic applications ttutoff is in the range [-89999, 93599] (i.e.,  more  than\n-25 hours and less than 26 hours); this allows easy support by implementations that already\nsupport the POSIX-required range [-24:59:59, 25:59:59].\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; the second is a signed integer specifying the total number of leap seconds to be  ap‐\nplied during the time period starting at the given time.  The pairs of values are sorted in\nascending order by time.  Each transition is for one leap second, either positive or  nega‐\ntive; transitions always separated by at least 28 days minus 1 second.\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 the\ntransition times associated with local time types were specified as UT or local time.  If a\nUT/local indicator is set, the corresponding standard/wall indicator must also 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  POSIX-style\nTZ  string  that  lacks  rules.   For  example, when TZ=\"EET-2EEST\" and there is no TZif file\n\"EET-2EEST\", the idea was to adapt the transition times from a TZif file with the  well-known\nname  \"posixrules\"  that  is  present  only  for  this purpose and is a copy of the file \"Eu‐\nrope/Brussels\", a file with a different UT offset.  POSIX  does  not  specify  this  obsolete\ntransformational  behavior,  the default rules are installation-dependent, and no implementa‐\ntion is known to support this feature for timestamps past 2037, so users desiring (say) Greek\ntime  should  instead specify TZ=\"Europe/Athens\" for better historical coverage, falling back\non TZ=\"EET-2EEST,M3.5.0/3,M10.5.0/4\" if POSIX conformance is required  and  older  timestamps\nneed 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, POSIX-TZ-environment-variable-style string for use in han‐\ndling instants after the last transition time stored in the file or for all instants  if  the\nfile  has no transitions.  The POSIX-style TZ string is empty (i.e., nothing between the new‐\nlines) if there is no POSIX representation for such instants.  If nonempty,  the  POSIX-style\nTZ  string  must  agree with the local time type after the last transition time if present in\nthe eight-byte data; for example, given the string “WET0WEST,M3.5.0,M10.5.0/3” then if a last\ntransition  time  is in July, the transition's local time type must specify a daylight-saving\ntime abbreviated “WEST” that is one hour east of UT.  Also, if there is at least one  transi‐\ntion,  time  type 0 is associated with the time period from the indefinite past up to but not\nincluding the earliest transition time.\n"
                },
                {
                    "name": "Version 3 format",
                    "content": "For version-3-format timezone files, the POSIX-TZ-style string may use two  minor  extensions\nto the POSIX 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": "Interoperability considerations",
                    "content": "Future changes to the format may append more data.\n\nVersion 1 files are considered a legacy format and should be avoided, as they do not  support\ntransition times after the year 2038.  Readers that only understand Version 1 must ignore any\ndata that extends beyond the calculated end of the version 1 data block.\n\nWriters should generate a version 3 file if TZ string extensions are necessary to  accurately\nmodel transition times.  Otherwise, version 2 files should be generated.\n\nThe  sequence of time changes defined by the version 1 header and data block should be a con‐\ntiguous subsequence 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 subsequence.  It also lets writers not supporting  ob‐\nsolescent readers use a tzhtimecnt of zero in the version 1 data block to save space.\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 3 file, readers should ignore the version 1 header and data block\nexcept 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"
                },
                {
                    "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  read‐\ners,\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 for‐\nmat 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 to allow simple partial workarounds in writ‐\ners  designed  to generate new-version data useful even for older-version readers.  This sec‐\ntion attempts to document these compatibility issues and workarounds, as well as to  document\nother common 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 as\nmuch 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 file's\nlast transition, because they cannot parse extensions to POSIX in the TZ-like string.  As a\npartial  workaround, a writer can output more transitions than necessary, so that only far-\nfuture timestamps are mishandled by version 2 readers.\n\n* Some readers designed for version 2 do not support permanent daylight saving time, e.g.,  a\nTZ  string “EST5EDT,0/0,J365/25” denoting permanent Eastern Daylight Time (-04).  As a par‐\ntial workaround, a writer can substitute standard time for the next time zone  east,  e.g.,\n“AST4” for permanent Atlantic Standard Time (-04).\n\n* Some readers ignore the footer, and instead predict future timestamps from the time type of\nthe last transition.  As a partial workaround, a writer can output  more  transitions  than\nnecessary.\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 time.\n\n* Some readers mishandle timestamps before the first transition that has a timestamp not less\nthan -231.  Readers that support only 32-bit timestamps are likely to be  more  prone  to\nthis problem, for example, when they process 64-bit transitions only some of which are rep‐\nresentable in 32 bits.  As a partial workaround, a writer can output a dummy transition  at\ntimestamp -231.\n\n* Some readers mishandle a transition if its timestamp has the minimum possible signed 64-bit\nvalue.  Timestamps less than -259 are not recommended.\n\n* Some readers mishandle POSIX-style TZ strings that contain “<” or “>”.  As a partial  work‐\naround, a writer can avoid using “<” or “>” for time zone abbreviations containing only al‐\nphabetic characters.\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 than 6\ncharacters, or that contain ASCII characters other than alphanumerics, “-”, and “+”.  These\nabbreviations 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 support\nlocations   like   Ireland,   which   uses   the   equivalent   of   the  POSIX  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 POSIX TZ string “GMT0IST,M3.5.0/1,M10.5.0”,  thus  swapping  standard\nand  daylight  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\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  time‐\nstamp.  Readers that do not support negative timestamps are likely to be more prone to this\nproblem.\n\n* Some readers mishandle time zone abbreviations like “-08” that contain “+”, “-”, or digits.\n\n* Some readers mishandle UT offsets that are out of the traditional range of -12 through  +12\nhours, 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, or\nof 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.  Internet\nRFC  8536  ⟨https://www.rfc-editor.org/info/rfc8536⟩  doi:10.17487/RFC8536  ⟨https://doi.org/\n10.17487/RFC8536⟩.\n",
            "subsections": []
        },
        "COLOPHON": {
            "content": "This  page  is  part  of  release  5.10 of the Linux man-pages project.  A description of the\nproject, information about reporting bugs, and the latest version of this page, can be  found\nat https://www.kernel.org/doc/man-pages/.\n\n\n\n2020-04-27                                    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"
        }
    ]
}