{
    "mode": "perldoc",
    "parameter": "Date::Manip::TZ",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/perldoc/Date%3A%3AManip%3A%3ATZ/json",
    "generated": "2026-06-12T07:01:46Z",
    "synopsis": "use Date::Manip::TZ;\n$tz = new Date::Manip::TZ;\nData for most (and hopefully all) time zones used around the world have been gathered and is\npublicly available in the zoneinfo (or Olson) database.\nThis module uses the data from the zoneinfo database to perform various time zone operations.",
    "sections": {
        "NAME": {
            "content": "Date::Manip::TZ - an interface to the time zone data\n",
            "subsections": []
        },
        "SYNOPSIS": {
            "content": "use Date::Manip::TZ;\n$tz = new Date::Manip::TZ;\n\nData for most (and hopefully all) time zones used around the world have been gathered and is\npublicly available in the zoneinfo (or Olson) database.\n\nThis module uses the data from the zoneinfo database to perform various time zone operations.\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "Every time zone has some of the following characteristics:\n\nname\nEvery time zone has a unique name. In the zoneinfo database, these are something similar to:\n\nAmerica/NewYork\n\naliases\nTime zones may have (but are not required to have) one or more aliases. Each alias is\nunique, and is not the same as any time zone name. An alias can be used in exactly the same\nway as a name.\n\nperiods\nEvery time zone is broken up into periods. Each period describes how a portion of time\nrelates to GMT, and how it might be expressed.\n\nEach period includes the following information:\n\nstart time, end time\nThe period begin and ends at certain times. The times are included both as an absolute GMT\ntime, and as a wall clock time. The wall clock start time is the time that will be on a\nclock just as the period starts (i.e. after a time change). The wall clock end time is the\ntime on a clock immediately before the period ends.\n\noffset\nThe entire period has an offset which is how much the wall clock time differs from GMT.\n\nabbreviation\nWhen expressing the time period, an abbreviation (such as EST) is typically used.\n\ndaylight saving time flag\nEvery period is categorized as a standard time or a daylight saving time. The flag will be 1\nif it is a daylight saving time, or 0 if it is a standard time.\n\nDate::Manip includes all of the data for all of the time zones from the zoneinfo database. This\ndata is available from:\n\n<ftp://ftp.iana.org/tz/>\n\nAdditional data from other standards are also used.\n\nThe zoneinfo database is not necessary in order to use Date::Manip. Instead, all of that data\nhas been extracted and stored in a series of other modules which are used to handle each time\nzone. In that way, Date::Manip has no dependency on any other source of data.\n\nThe Date::Manip::Zones document contains detailed information on the data available.\n",
            "subsections": []
        },
        "METHODS": {
            "content": "In all methods, the following variables are used:\n\n$zone\nThis is a string which contains a valid time zone name. For example:\n\nAmerica/NewYork\n\n$alias\nThis is a strings which contains a valid time zone name, or a valid time zone alias. For\nexample:\n\nAmerica/NewYork\nUS/Eastern\nEST5EDT\n\n$abbrev\nThis is a string which contains a valid time zone abbreviation. For example:\n\nEST\n\n$offset\nThis is a time zone entered as an offset. An offset is either a string of one of the\nformats:\n\n+HH\n+HHMM\n+HHMMSS\n+HH:MM\n+HH:MM:SS\n\nor it can be a list reference:\n\n[HH,MM,SS]\n\nIf a list reference is used, the sign must be included with all values. So, the offset\n\"-05:30\" would be the list reference:\n\n[-5,-30,0]\n\n$dstflag\nThis is always one of the values: std, stdonly, dst, dstonly\n\nIt defaults to \"std\" if it is not present. When determining a time zone, it is usually\nnecessary to check a number of different time zone and DST combinations.\n\nIf $dstflag is \"std\", it will check both standard and daylight saving times, but will give\npreference to standard times. If $dstflag is \"stdonly\", only standard times will be checked.\n\nThe \"dst\" flag will search both, but give preference to daylight saving times. The \"dstonly\"\nvalues will only use daylight saving times.\n\n$date\nA date is always a string containing a date in one of the formats:\n\nYYYYMMDDHH:MN:SS\nYYYY-MM-DD-HH:MN:SS\nYYYYMMDDHHMNSS\n\nor a list reference:\n\n[Y,M,D,H,MN,S]\n\n$isdst\nThis is 0 if a date is in standard time, 1 if it is in daylight saving time.\n\n$period\nA period is a list reference currently containing the following items:\n\n[ $dateUT, $dateLT, $offsetstr, $offset, $abbrev, $isdst,\n$endUT, $endLT, $begUTs, $begLTs, $endUTs, $endLTs ]\n\n$dateUT and $dateLT are the starting date of the period (i.e. the first second in a period)\nin universal (GMT) time and local (wall clock) time. $endUT and $endLT are the end date of\nthe period (i.e. the last second in a period) in universal and local time. These are all\nstored as list references.\n\n$offsetstr is the string representation of the offset (\"+05:00:00\") and $offset is the\ncorresponding list reference form ([5,0,0]).\n\n$abbrev is the abbreviation that applies during this period, and $isdst is 0 or 1 if it is\nstandard or daylight saving time.\n\nWhen accessing the elements in a period, use ONLY positive indices. In other words, to get\n$endUT, access it as $$period[6], NOT as $$period[-2], since I am considering adding more\ninformation to the period description that may speed up performance.\n\n$begUTs is the string representation (YYYYMMDDHH:MN:SS) of $begUT. Similar for $begLTs,\n$endUTs, and $endLTs.\n\nThe following methods are available:\n\nbase\nconfig\nerr\nnew\nnewconfig\nPlease refer to the Date::Manip::Obj documentation for these methods.\n\nallperiods\n@periods = $tz->allperiods($zone,$year);\n\nThis returns the description of all time zone periods that occur (in full or in part) during\nthe given year. The year is measured in universal (GMT) time.\n\nconvert\nconverttogmt\nconvertfromgmt\nconverttolocal\nconvertfromlocal\nThese functions convert a date from one time zone to another.\n\n($err,$date,$offset,$isdst,$abbrev) =\n$tz->convert($date,$from,$to [,$isdst]);\n\nThis converts a date in the time zone given by $from to the time zone given by $to.\n\n($err,$date,$offset,$isdst,$abbrev) =\n$tz->converttogmt($date [,$from] [,$isdst]);\n\nThis converts a date to GMT. If $from is given, it is the current time zone of the date. If\n$from is omitted, it defaults to the local time zone.\n\nThe value of $isdst returned is always 0.\n\n($err,$date,$offset,$isdst,$abbrev) =\n$tz->convertfromgmt($date [,$to]);\n\nThis converts a date from GMT to another time zone. If $to is given, the date is converted\nto that time zone. Otherwise, it is converted to the local time zone.\n\n($err,$date,$offset,$isdst,$abbrev) =\n$tz->converttolocal($date [,$from] [,$isdst]);\n($err,$date,$offset,$isdst,$abbrev) =\n$tz->convertfromlocal($date [,$to] [,$isdst]);\n\nSimilar to the converttogmt and convertfromgmt functions. If $from or $to are omitted,\nthey default to GMT.\n\nIf there is any ambiguity about whether $date is in DST or not (i.e. if it is a date that is\nrepeated during a time change due to the clock being moved back), the $isdst option can be\npassed in as an argument (it should be 0 or 1) to say which time to use. It is ignored in\nall cases where $date can be determined without that information.\n\nThe $isdst value passed back is 1 if the converted date is in DST. The $offset value passed\nback is a list reference containing the offset from GMT. $abbrev passed back is the time\nzone abbreviation.\n\nError codes are:\n\n0  No error\n1  Invalid arguments\n2  Invalid FROM zone\n3  Invalid TO zone\n4  Invalid date\n\ncurrzone\n$tz->currzone();\n\nThis returns the system time zone. The system time zone is determined using the methods\ndescribed below in the \"DETERMINING THE SYSTEM TIME ZONE\" section.\n\nThis is the time zone that is used by default unless the SetDate or ForceDate config\nvariable is set to a different zone.\n\n$tz->currzone(1);\n\nThis clears the system time zone and re-determines it using the methods described below.\n\nThe main reason to do this is if the currzonemethods method is used to change how the time\nzone is determined.\n\ncurrzonemethods\n$tz->currzonemethods(@methods);\n\nThis sets the list and order of methods to use in determining the local time zone. The\nvarious methods available are listed below in the section \"DETERMINING THE SYSTEM TIME\nZONE\".\n\nSome methods may require one or more arguments. For example, the method named \"mainvar\"\ntakes an option that is the name of a variable. The arguments must be included in the\n@methods list immediately after the method name (so @methods is actually a mixture of method\nnames and arguments).\n\nThis method may not be used in any environment where taint checking is enabled. If it is, it\nwill issue a warning, but will NOT change the method list.\n\ndateperiod\n$period = $tz->dateperiod($date,$zone,$wallclock [,$isdst]);\n\nThis returns the period information for the given date. $date defaults to GMT, but may be\ngiven as local (i.e. wall clock) time if $wallclock is non-zero. The period information is\ndescribed in the periods method below.\n\nIf a wall clock time is given, no period is returned if the wall clock time doesn't ever\nappear (such as when a time change results in the clock moving forward \"skipping\" a period\nof time). If the wall clock time appears twice (i.e. when a time change results in the clock\nbeing set back), the $isdst variable is used. The standard time is used unless $isdst is\nnon-zero. $isdst is ignored except in the case where there are two possible periods.\n\ndefineabbrev\n($err,$val) = $tz->defineabbrev($abbrev,@zone);\n\nWhen encountering an abbreviation, by default, all time zones which ever include the\nabbreviation will be examine in the order given in the Date::Manip::Zones manual.\n\nOccasionally, it may be necessary to change the order. This is true if you are parsing dates\nin a time zone which uses an abbreviation which is also used in another time zone, and where\nthe other time zone is given preference. As an example, the abbreviation \"ADT\" will default\nto the \"Atlantic/Bermuda\" time zone. If you are in the \"America/Halifax\" time zone (which\nalso uses that abbreviation), you may want to change the order of time zones.\n\nThis will take an abbreviation (which must be a known abbreviation... there is no means of\ndefining a totally new abbreviation) and a list of zones. This will set the list of zones\nthat will be checked, and the order in which they are checked, when a date is encountered\nwith the given abbreviation. It is not necessary that the list include every zone that has\never used the abbreviation, but it may not include a zone that has never used it.\n\nIf $abbrev is \"reset\", all abbreviations are reset to the standard values. If @zone includes\nonly the element 'reset', the default list for $abbrev is restored.\n\nThe following error codes are returned:\n\n0  No error\n1  $abbrev is not a valid abbreviation in any time zone\n2  A zone (returned as $val) is not a valid time zone\n3  A zone (returned as $val) does not use the abbreviation\n\nFor more information about the different zones which may correspond to each abbreviation,\nand the order in which they will be examined by default, refer to the Date::Manip::Zones\nmanual.\n\ndefinealias\n$err = $tz->definealias($alias,$zone);\n\nThis will define a new alias (or override an existing alias). $zone must be a valid zone or\nan error is returned.\n\nFor more information about the different aliases which are set by default, refer to the\nDate::Manip::Zones manual.\n\nIf $alias is \"reset\", all aliases will be reset to the standard values. If $zone is \"reset\",\n$alias will be reset to the standard value.\n\ndefineoffset\n($err,$val) = $tz->defineoffset($offset, [$dstflag,] @zone);\n\nThis is similar to the defineabbrev method. When an offset is encountered, all time zones\nwhich have ever included that offset are checked. This will defined which time zones, and in\nwhat order, they should be checked.\n\nThe zones to both standard and daylight saving times which include the offset (if $dstflag\nis \"std\" or \"dst\") or to only one or the other.\n\nIf $offset is \"reset\", all lists are reset to the default values. If @zone includes only the\nelement 'reset', the default list and order is restored for $offset ($dstflag must not be\ngiven).\n\nThe following error codes are returned:\n\n0  No error\n1  $offset is not a valid offset in any time zone\n2  $offset is not a valid offset in the selected\ntime (if doing \"dstonly\" or \"stdonly\")\n3  A zone (returned as $val) is not a valid time zone\n4  A zone (returned as $val) does not use the offset\n5  A zone (returned as $val) does not include the\noffset in the selected time (if doing \"dstonly\"\nor \"stdonly\")\n\n9  Offset is not a valid offset\n\nperiods\n@periods = $tz->periods($zone,$year);\n\nThis returns the description of all time zone periods that begin during the year given. The\nyear is measured in universal (GMT) time.\n\nIf no time zone period starts in the given year, nothing is returned.\n\n@periods = $tz->periods($zone,undef,$year);\n\nThis returns all periods that begin in any year from 0001 to $year.\n\n@periods = $tz->periods($zone,$year0,$year1);\n\nThis returns all periods that begin in any year from $year0 to $year1.\n\ntzdata\ntzcode\n$vers = $tz->tzdata();\n$vers = $tz->tzcode();\n\nThese return the versions of the tzdata and tzcode packages used to generate the modules.\n\nzone\n$zone = $tz->zone(@args);\n@zone = $tz->zone(@args);\n\nThis function will return a list of all zones, or the default zone, which matches all of the\nsupplied information. In scalar context, it will return only the default zone. In list\ncontext, it will return all zones.\n\n@args may include any of the following items, and the order is not important.\n\nA zone name or alias ($alias)\n\nA zone abbreviation ($abbrev)\n\nAn offset ($offset)\n\nA dstflag ($dstflag)\n\nA date ($date)\n\nIt is NOT valid to include two of any of the items. Any time zone returned will match all of\nthe data supplied.\n\nIf an error occurs, undef is returned. If no zone matches, an empty string, or an empty list\nis returned.\n\nThe order of the zones will be determined in the following way:\n\nIf $abbrev is given, the order of time zones will be determined by it (and $dstflag). If\n$dstflag is \"std\", all zones which match $abbrev in standard time are included, followed by\nall that match $abbrev in saving time (but no duplication is allowed). The reverse is true\nif $dstflag is \"dst\".\n\nIf $abbrev is not given, but $offset is, $offset (and $dstflag) will determine the order\ngiven. If $dstflag is \"std\", all zones which match $offset in standard time are included,\nfollowed by all that match $offset in saving time (but no duplication is allowed). The\nreverse is true if $dstflag is \"dst\".\n\nIf $date is given, only zones in which $date will appear in a zone that matches all other\ninformation are given. $date is a wall clock time.\n\nIf no $zone, $abbrev, or $offset are entered, the local time zone may be returned (unless\n$date is entered, and it doesn't exist in the local time zone).\n\nNOTE: there is one important thing to note with respect to $dstflag when you are working\nwith a timezone expressed as an offset and a date is passed in. In this case, the default\nvalue of $dstflag is \"dst\" (NOT \"stdonly\"), and you probably never want to pass in a value\nof \"std\" (though passing in \"stdonly\" is okay).\n\nFor standard offsets (with no minute component), there is always a standard timezone which\nmatches that offset. For example, the timezone \"+0100\" matches the timezone \"Etc/GMT+01\", so\nyou will never get a timezone in daylight saving time if $dstflag is \"std\".\n\nIf you want to pass in a date of 2001-07-01-00:00:00 and an timezone of \"+0100\" and you want\nto get a timezone that refers to that date as a daylight saving time date, you must use the\n$dstflag of \"dst\" (or \"dstonly\").\n\nBecause this is almost always the behavior desired, when a zone is passed in as an offset,\nand a date is passed in, the default $dstflag is \"dst\" instead of \"std\". In all other\nsituations, the default is still \"std\".\n\nIf the timezone is expressed as an abbreviation, this problem does not occur.\n\nTIME ZONE INFORMATION IN DATE::MANIP\nDate::Manip makes use of three potentially different time zones when working with a date.\n\nThe first time zone that may be used is the actual local time zone. This is the time zone that\nthe computer is actually running in.\n\nThe second time zone is the working time zone. Usually, you will want the default time zone to\nbe the local time zone, but occasionally, you may want the default time zone to be different.\n\nThe third time zone is the actual time zone that was parsed, or set, for a date. If a date\ncontains no time zone information, it will default to the working time zone.\n\nThe local time zone is determined using the methods described in the following section. Methods\nexist for locating the zone in one of the system configuration files, determining it by running\na system command, or by looking it up in the registry (for Windows operating systems). If all of\nthese methods fail, the local time zone may be set using either the $::TZ or $ENV{TZ} variables.\nPlease note that these should ONLY be used to set the actual local time zone.\n\nIf you are running in one time zone, but you want to force dates to be specified in an alternate\ntime zone by default, you need to set the working time zone. The working time zone defaults to\nthe local time zone, but this can be changed using either the SetDate or ForceDate config\nvariables. Refer to the Date::Manip::Config manual for more information.\n\nFinally, when a date is actually parsed, if it contains any time zone information, the date is\nstored in that time zone.\n",
            "subsections": []
        },
        "DETERMINING THE SYSTEM TIME ZONE": {
            "content": "There are a large number of ways available for determining the time zone. Some or all of them\nmay be checked. A list of methods to use is provided by default, and may be overridden by the\ncurrzonemethods function described above. To override the default order and/or list of\nmethods, just pass in a list of method names (with arguments where necessary), and only those\nmethods will be done, and in the order given.\n\nThe following methods are available:\n\nMethod     Argument(s)    Procedure\n======     ===========    =========\n\nmain       VAR            The main variable named VAR is\nchecked. E.g. \"main TZ\" checks\nthe variable $::TZ .\n\nenv        TYPE VAR       The named environment variable\nis checked and the type of\ndata stored there (TYPE can\nbe 'zone' or 'offset' which\nis the number of seconds from\nUTC).\n\nfile       FILE           Look in the given file for any\none of the following case\ninsensitive lines:\nZONE\ntz = ZONE\nzone = ZONE\ntimezone = ZONE\nZONE may be quoted (single or\ndouble) and whitespace is\nignored (except that underscores\nin the zone name may be replaced\nby whitespace on some OSes). If\nthe entire line is a zone, it must\nbe the first non-blank non-comment\nline in the file.\n\ncommand    COMMAND        Runs a command which produces\na time zone as the output.\n\ncmdfield   COMMAND N      Runs a command which produces\nwhitespace separated fields,\nthe Nth one containing the\ntime zone (fields are numbered\nstarting at 0, or from the\nend starting at -1).\n\ngmtoff                    Uses the current offset from\nGMT to come up with a best guess.\n\ntzdata     FILE DIR       This uses a system config file that\ncontains a pointer to the local tzdata\nfiles to  determine the timezone.  On\nmany operating systems, use:\n\ntzdata /etc/localtime /usr/share/zoneinfo\n\nFILE is the system file.  DIR is the\ndirectory where the tzdata files are stored.\n\nThe config file is either a link to a file\nin the tzdata directory or a copy of one\nof the files.\n\nregistry                  Look up the value in the\nWindows registry. This is only\navailable to hosts running a\nWindows operating system.\n\nNote that the \"main\" and \"env\" methods should only be used to specify the actual time zone the\nsystem is running in. Use the SetDate and ForceDate config variables to specify an alternate\ntime zone that you want to work in.\n\nBy default, the following methods are checked (in the order given) on Unix systems:\n\nmain     TZ\nenv      zone TZ\nfile     /etc/TIMEZONE\nfile     /etc/timezone\nfile     /etc/sysconfig/clock\nfile     /etc/default/init\ncommand  \"/bin/date +%Z\"\ncommand  \"/usr/bin/date +%Z\"\ncommand  \"/usr/local/bin/date +%Z\"\ncmdfield /bin/date             -2\ncmdfield /usr/bin/date         -2\ncmdfield /usr/local/bin/date   -2\ncommand  \"/bin/date +%z\"\ncommand  \"/usr/bin/date +%z\"\ncommand  \"/usr/local/bin/date +%z\"\ntzdata   /etc/localtime /usr/share/zoneinfo\ngmtoff\n\nThe default methods for Windows systems are:\n\nmain     TZ\nenv      zone TZ\nregistry\ngmtoff\n\nThe default methods for VMS systems are:\n\nmain     TZ\nenv      zone TZ\nenv      zone SYS$TIMEZONENAME\nenv      zone UCX$TZ\nenv      zone TCPIP$TZ\nenv      zone MULTINETTIMEZONE\nenv      offset SYS$TIMEZONEDIFFERENTIAL\ngmtoff\n\nThe default methods for all other systems are:\n\nmain     TZ\nenv      zone TZ\ngmtoff\n\nIf anyone wants better support for a specific OS, please contact me and we'll coordinate adding\nit.\n\nIn all cases, the value returned from the method may be any of the following:\n\nthe full name of a time zone (e.g. America/NewYork)\nor an alias\n\nan abbreviation (e.g. EDT) which will be used to\ndetermine the zone if possible\n\nan offset (+hh, +hhmn, +hh:mm, +hh:mm:ss) from GMT\n\nThe Date::Manip::Zones module contains information about the time zones and aliases available,\nand what time zones contain the abbreviations.\n",
            "subsections": []
        },
        "DESIGN ISSUES": {
            "content": "The design decisions made in writing this module may cause some questions (and probably\ncomplaints). The time zone modules are all generated using scripts (included in the Date::Manip\ndistribution) which use the standard tzdata tools to parse the tzdata files and store that\ninformation in perl modules.\n\nI'd like to address some of them, to avoid answering some of the \"why did you do it that way\"\nremarks. I do welcome discussion about these decisions... but preferably after you understand\nwhy those decisions were made so that that we have an informed basis to begin a discussion.\n\nWhy not use existing zoneinfo files\nSome people will probably think that I should have written an interface to the zoneinfo\nfiles which are distributed with most operating systems. Although I considered doing that, I\nrejected the idea for two reasons.\n\nFirst, not all operating systems come with the zoneinfo databases in a user accessible state\n(Microsoft for example). Even those that do include them store the information in various\nformats and locations. In order to bypass all that, I have included the data directly in\nthese modules.\n\nSecond, as I was doing my initial investigations into this, I ran into a bug in the Solaris\nzoneinfo tools (long since fixed I'm sure). I decided then that I didn't want to depend on\nan implementation where I could not control and fix the bugs.\n\nWhy not use the native tzdata files\nAnother decision people may question is that I parse the tzdata files and store the data\nfrom them in a large number of perl modules instead of creating an interface to the tzdata\nfiles directly. This was done solely for the sake of speed. Date::Manip is already a slow\nmodule. I didn't want to slow it down further by doing the complex parsing required to\ninterpret the tzdata files while manipulating dates. By storing the data in these modules,\nthere is little or no parsing done while using Date::Manip modules. It costs a little disk\nspace to store this information... but very little of it is actually loaded at runtime (time\nzone data is only loaded when the time zone is actually referred to), so I feel it's a good\ntradeoff.\n\nWhy store the information in so many files\nThe data from the native tzdata files are parsed and stored in two sets of modules. These\ninclude almost 500 Date::Manip::Offset::* modules and almost 450 Date::Manip::TZ::* modules.\n\nI note that on my linux box, /usr/share/zoneinfo (which contains data files generated from\nthe tzdata files) contains over 1700 files, so I'm not doing anything \"new\" by breaking up\nthe information into separate files. And doing so has a huge impact on performance... it is\nnot necessary to load and/or manipulate data from time zones which are not in use.\n\nThe minute I made the decision to distribute the timezone information myself, as opposed to\nusing the system version, it was a given that there would be a lot of files.\n\nThese modules are loaded only when the time zone or offset is actually used, so, unless\ndates from around the world are being parsed, only a very small number of these modules will\nactually be loaded. In many applications, only a single TZ module will be loaded. If parsing\ndates which have timezone information stored as offsets, one or two Offset modules will also\nbe loaded.\n\nThe disk space seems excessive\nCurrently, the disk usage of the perl files is around 9 MB. Total disk usage for\n/usr/share/zoneinfo on my computer is around 4 MB. There are a couple of differences.\n\nThe primary difference is that the zoneinfo files are stored in a binary (and hence, more\ncompressed) version, where the perl modules have all the data in pure text.\n\nSince these are all automatically generated and used, it may be beneficial to store the data\nin some packed binary format instead of the fully expanded text form that is currently in\nuse. This would decrease the disk space usage, and might improve performance. However, the\nperformance improvement would happen only once per timezone, and would make for more\ncomplicated code, so I'm not very interested in pursuing this.\n\nAnother aspect of the current modules is that they all include pod documentation. Although\nnot necessary, this allows users to easily see what modules handle which time zones, and\nthat's nice. It also allows me to use podcoverage tests for the module which is a nice\ncheck to make sure that the documentation is accurate.\n\nAll told, I don't consider the disk usage excessive at all.\n",
            "subsections": []
        },
        "KNOWN PROBLEMS OR ISSUES": {
            "content": "Unable to determine Time Zone\nWhen using Date::Manip, when the module is initialized, it must be able to determine the\nlocal time zone. If it fails to do so, an error will occur:\n\nUnable to determine Time Zone\n\nand the script will exit.\n\nIn the past, this was the most common problem with using Date::Manip . With the release of\n6.00, this problem should be significantly less common. If you do get this error, please\nrefer to the section above DETERMINING THE SYSTEM TIME ZONE for information about\ndetermining the local time zone. I am also interested in hearing about this so that I can\nupdate the default list of methods to be able to determine the local time zone better.\n\nAsia/Jerusalem time zone\nThe Asia/Jerusalem time zone has a non-standard way of specifying the start and end of\nDaylight Saving Time based on the Hebrew calendar.\n\nAs a result, there is no way to specify a simple rule to define time zone changes for all\nyears in the future. As such, this module supports all time zone changes currently specified\nin the zoneinfo database (which currently goes to the year 2037) but does not attempt to\ncorrectly handle zone changes beyond that date. As a result, Date::Manip should not be used\nto parse dates in the Jerusalem time zone that are far enough in the future that information\nis not included in the current version of the zoneinfo database.\n\nLMT and zzz abbreviations\nBoth the LMT and zzz abbreviations are used in the zoneinfo databases. LMT is use for most\ntime zones for the times before the Gregorian calendar was adopted, and zzz is used for a\nfew where the time zone was created and no description of dates prior to that are supported.\nBoth LMT and zzz are basically ignored in parsing dates (because there is no reasonable way\nto determine which zone they are referring to), and will be treated as the local time zone\nregardless.\n",
            "subsections": []
        },
        "KNOWN BUGS": {
            "content": "None known.\n",
            "subsections": []
        },
        "BUGS AND QUESTIONS": {
            "content": "Please refer to the Date::Manip::Problems documentation for information on submitting bug\nreports or questions to the author.\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "Date::Manip - main module documentation\n",
            "subsections": []
        },
        "LICENSE": {
            "content": "This script is free software; you can redistribute it and/or modify it under the same terms as\nPerl itself.\n",
            "subsections": []
        },
        "AUTHOR": {
            "content": "Sullivan Beck (sbeck@cpan.org)\n",
            "subsections": []
        }
    },
    "summary": "Date::Manip::TZ - an interface to the time zone data",
    "flags": [],
    "examples": [],
    "see_also": []
}