{
    "mode": "perldoc",
    "parameter": "Date::Manip::Changes5to6",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/perldoc/Date%3A%3AManip%3A%3AChanges5to6/json",
    "generated": "2026-07-05T13:00:16Z",
    "synopsis": "Date::Manip 6.00 represents a complete rethink and rewrite of Date::Manip. A great deal of\neffort was made to make sure that 6.00 is almost backwards compatible with 5.xx whenever\nfeasible, but some functionality has changed in backwards incompatible ways. Other parts have\nbeen deprecated and will be removed at some point in the future.\nThis document describes the differences between the 5.xx series and version 6.00. This page\nprimarily describes technical details, most of which do not impact how Date::Manip is used in\nscripts. If you want to make sure that a script which ran with 5.xx will run with 6.xx, refer to\nthe Date::Manip::Migration5to6 document.",
    "sections": {
        "NAME": {
            "content": "Date::Manip::Changes5to6 - describes differences between 5.xx and 6.00\n",
            "subsections": []
        },
        "SYNOPSIS": {
            "content": "Date::Manip 6.00 represents a complete rethink and rewrite of Date::Manip. A great deal of\neffort was made to make sure that 6.00 is almost backwards compatible with 5.xx whenever\nfeasible, but some functionality has changed in backwards incompatible ways. Other parts have\nbeen deprecated and will be removed at some point in the future.\n\nThis document describes the differences between the 5.xx series and version 6.00. This page\nprimarily describes technical details, most of which do not impact how Date::Manip is used in\nscripts. If you want to make sure that a script which ran with 5.xx will run with 6.xx, refer to\nthe Date::Manip::Migration5to6 document.\n",
            "subsections": []
        },
        "OVERVIEW": {
            "content": "The Date::Manip 5.xx series of suffered from several weaknesses. These included:\n\nPoor time zone support\nTime zone support in 5.xx was broken. Determining a time zone, and understanding daylight\nsaving time changes was incomplete (at best) and totally inadequate to do true timezone\noperations.\n\nParsing too complicated and unstructured\nThe parsing routines had grown very complicated, and overly permissive over time and were in\nneed of a complete overhaul.\n\nLacking OO model\nDate::Manip 5.xx was written as a functional module, not an OO module, but date handling\nwould lend itself very well to being OO with different classes to handle dates, deltas, and\nrecurrences.\n\nThe OO model allows a lot of information to be stored with each date (such as time zone\ninformation) which is discarded in the functional interface.\n\nToo monolithic\nThe entire Date::Manip module was contained in one huge file. Breaking up the module would\nmake it much easier to deal with.\n\nDate::Manip 6.00 is a complete rewrite of Date::Manip to address these and other issues.\n\nThe following sections address how Date::Manip 6.00 differs from previous releases, and\ndescribes changes that might need to be made to your script in order to upgrade from 5.xx to\n6.00.\n\nThe most important changes are marked with asterisks.\n",
            "subsections": []
        },
        "GENERAL CHANGES": {
            "content": "(*) Requires perl 5.10.0\nPlease see the Date::Manip::Problems document for a discussion of this problem. It's in the\nKNOWN COMPLAINTS section.\n\n(*) Breaking into smaller modules\nDate::Manip module has been broken up from one huge module into a large number of smaller\nmore manageable modules. The main Date::Manip module is still present, and contains all of\nthe functions from Date::Manip 5.xx (except that they now call functions from all the other\nmodules to do the actual work). In general, the Date::Manip module from 6.00 is backwards\ncompatible.\n\nA number of new modules have been created as well. These can be used directly, bypassing the\nmain Date::Manip module. These include the following:\n\nDate::Manip::Base contains many basic date operations which may be used to do simple date\nmanipulation tasks without all the overhead of the full Date::Manip module.\n\nDate::Manip::TZ contains time zone operations.\n\nHandling dates, deltas, and recurrences are now done in Date::Manip::Date,\nDate::Manip::Delta, and Date::Manip::Recur.\n\nAll of these modules are object oriented, and are designed to be used directly, so if you\nprefer an OO interface over a functional interface, use these modules.\n\n(*) Intermediate data cached\nIn order to improve the performance of Date::Manip, many intermediate values are cached.\nThis does impact the memory footprint of the module, but it has a huge impact on the\nperformance of the module.\n\nSome types of data depend on the config variables used, and these are cached separately, and\nthis cache is automatically cleared every time a config variable is set. As a result, it is\nbest if you set all config variables at the start, and then leave them alone completely to\nget optimal use of cached data.\n\nA side effect of all this is that the Memoize module should not be used in conjunction with\nDate::Manip.\n\nIn the version 5.xx documentation, it was mentioned that the Memoize module might be used to\nimprove performance in some cases. This is no longer the case. It should not be used with\nDate::Manip, even if you use the functional interface instead of the OO interface.\n\nTaint safe\nDate::Manip now contains no tainted data, and should run without problems with taint\nchecking on provided you do not set additional methods for determining the system time zone\nusing the currzonemethods function.\n\nIdeally, this should never be necessary. If it is necessary, I'd like to hear about it so\nthat I can add whatever standard methods are needed to the built in list.\n",
            "subsections": []
        },
        "TIME ZONE SUPPORT": {
            "content": "(*) Complete handling of time zones\nThe biggest problem with Date::Manip 5.xx was it's inability to correctly handle time zones\nand Daylight Saving Time. That is now fixed. Version 6.00 includes support for every time\nzone included in the zoneinfo (aka Olson) database which includes the definitions of\n(hopefully) all of the time zones used in the world.\n\nIndividual time zones will no longer be added\nPrior to 5.55, time zones were added upon request. Since 6.00 now supports a full set of\nstandard time zones, I will no longer add in individual time zones (Date::Manip::TZ includes\nfunctionality for adding them yourself if they are needed). With Date::Manip now having full\ntime zone support, I'm not interested in supporting my own time zone database.\n\nHowever, I am interested in adding sets of time zones from various \"standards\".\n\nDate::Manip 6.00 includes time zones from the following standards:\n\nOlson zoneinfo database\nall Microsoft Windows time zones\nzones listed in RFC-822\n\nIf there are additional standards that include additional time zones not included here,\nplease point me to them so they can be added. This could include published lists of time\nzone names supported on some operating system which have different names than the zoneinfo\nlist.\n\nNonstandard time zone abbreviations removed\nSome of the individual standards that were added in the 5.xx series are not included in any\nof the standards listed above.\n\nAs of 6.00, only time zones from standards will be included in the distribution (others can\nbe added by users using the functions described in Date::Manip::TZ to add aliases for\nexisting time zones).\n\nThe following time zones were in Date::Manip 5.xx but not in 6.00.\n\nIDLW    -1200    International Date Line West\nNT      -1100    Nome\nSAT     -0400    Chile\nCLDT    -0300    Chile Daylight\nAT      -0200    Azores\nMEWT    +0100    Middle European Winter\nMEZ     +0100    Middle European\nFWT     +0100    French Winter\nGB      +0100    GMT with daylight saving\nSWT     +0100    Swedish Winter\nMESZ    +0200    Middle European Summer\nFST     +0200    French Summer\nMETDST  +0200    An alias for MEST used by HP-UX\nEETDST  +0300    An alias for eest used by HP-UX\nEETEDT  +0300    Eastern Europe, USSR Zone 1\nBT      +0300    Baghdad, USSR Zone 2\nIT      +0330    Iran\nZP4     +0400    USSR Zone 3\nZP5     +0500    USSR Zone 4\nIST     +0530    Indian Standard\nZP6     +0600    USSR Zone 5\nAWST    +0800    Australian Western Standard\nROK     +0900    Republic of Korea\nAEST    +1000    Australian Eastern Standard\nACDT    +1030    Australian Central Daylight\nCADT    +1030    Central Australian Daylight\nAEDT    +1100    Australian Eastern Daylight\nEADT    +1100    Eastern Australian Daylight\nNZT     +1200    New Zealand\nIDLE    +1200    International Date Line East\n\nA lot of support modules and files\nDate::Manip now includes a large number of files and modules that are used to support time\nzones.\n\nA series of modules are included which are auto-generated from the zoneinfo database. The\nDate::Manip::Zones, Date::Manip::TZ::*, and Date::Manip::Offset::* modules are all\nautomatically generated and are not intended to be used directly. Instead, the\nDate::Manip::TZ module is used to access the data stored there.\n\nA separate time zone module (Date::Manip::TZ::*) is included for every single time zone.\nThere is also a module (Date::Manip::Offset::*) for every different offset. All told, there\nare almost 1000 modules. These are included to make time zone handling more efficient.\nRather than calculating everything on the fly, information about each time zone and offset\nare included here which greatly speeds up the handling of time zones. These modules are only\nloaded as needed (i.e. only the modules related to the specific time zones you refer to are\never loaded), so there is no performance penalty to having them.\n\nAlso included in the distribution are a script (tzdata) and additional module\n(Date::Manip::TZdata). These are used to automatically generate the time zone modules, and\nare of no use to anyone other than the maintainer of Date::Manip. They are included solely\nfor the sake of completeness. If someone wanted to fork Date::Manip, all the tools necessary\nto do so are included in the distribution.\n\n(*) Meaning of $::TZ and $ENV{TZ}\nIn Date::Manip 5.x, you could specify what time zone you wanted to work in using either the\n$::TZ or $ENV{TZ} variables.\n\nDate::Manip 6.00 makes use of two different time zones: the actual local time zone the\ncomputer is running in (and which is used by the system clock), and a time zone that you\nwant to work in. Typically, these are the same, but they do not have to be.\n\nAs of Date::Manip 6.00, the $::TZ and $ENV{TZ} variables are used only to specify the actual\nlocal time zone.\n\nIn order to specify an alternate time zone to work in, use the SetDate or ForceDate config\nvariables.\n",
            "subsections": []
        },
        "CONFIG FILES AND VARIABLES": {
            "content": "(*) DateInit handling of config variables\nThe handling of config variables has changed slightly.\n\nPreviously, variables passed in to DateInit overrode values from config files. This has\nchanged slightly. Options to DateInit are now parsed in the order they are listed, so the\nfollowing:\n\nDateInit(\"DateFormat=Other\",\"ConfigFile=DateManip.cnf\")\n\nwould first set the DateFormat variable, and then it would read the config file\n\"DateManip.cnf\". If that config file included a DateFormat definition, it would override the\none passed in to DateInit.\n\nThe proper way to override config files is to pass the config files in first, followed by\nany script-specific overrides. In other words:\n\nDateInit(\"ConfigFile=DateManip.cnf\",\"DateFormat=Other\")\n\nDateInit doesn't return the config variables\nIn Date::Manip::5.xx, DateInit could return the list of all config variables. This\nfunctionality is no longer supported. DateInit is used strictly to set config variables.\n\n(*) Config file options\nDate::Manip 5.xx had the concept of a global and personal config file. In addition, the\npersonal config file could be looked for in a path of directories. All this was specified\nusing the config variables:\n\nGlobalCnf\nIgnoreGlobalCnf\nPersonalCnf\nPersonalCnfPath\nPathSep\n\nAll of these have been removed. Instead, the single config variable:\n\nConfigFile\n\nwill be used to specify config files (with no distinction between a global and personal\nconfig file). Also, no path searching is done. Each must be specified by a complete path.\nFinally, any number of config files can be used. So the following is valid:\n\nDateInit(\"ConfigFile=./Manip.cnf\",\"ConfigFile=/tmp/Manip.cnf\")\n\nOther config variables removed\nThe following config variables have been removed.\n\nTodayIsMidnight  Use DefaultTime instead.\n\nConvTZ           Use SetDate or ForceDate instead.\n\nInternal         Use Printable instead.\n\nDeltaSigns       Use the Date::Manip::Delta::printf\nmethod to print deltas\n\nUpdateCurrTZ     With real time zone handling in\nplace, this is no longer necessary\n\nIntCharSet      This has been replaced with better support for\ninternational character sets. The Encoding config\nvariable may be used instead.\n\nOther config variables deprecated\nThe following config variables are deprecated and will be removed in some future version:\n\nTZ              Use SetDate or ForceDate instead.\n\nHolidays\nPreviously, holidays could be defined as a \"Date + Delta\" or \"Date - Delta\" string. These\npredate recurrences, and introduce some complexity into the handling of holidays. Since\nrecurrences are a much better way to define holidays, the \"Date + Delta\" and \"Date - Delta\"\nstrings are no longer supported.\n\nTZ replaced (and enhanced)\nThe SetDate and ForceDate variables (which include the functionality of the deprecated TZ\nvariable) are much improved as described in the Date::Manip::Config documentation.\n\nSince it is now handles time change correctly (allowing time changes to occur in the\nalternate time zone), parsed results may be different than in 5.x (but since 5.x didn't have\nproper time zone handling, this is a good thing).\n",
            "subsections": []
        },
        "DATE PARSING AND OPERATIONS": {
            "content": "(*) today, tomorrow, yesterday\nThe words \"today\", \"tomorrow\", and \"yesterday\" in 5.xx referred to the time now, 24 hours in\nthe future, and 24 hours in the past respectively.\n\nAs of 6.00, these are treated strictly as date strings, so they are the current day, the day\nbefore, or the day after at the time 00:00:00.\n\nThe string \"now\" still refers to the current date and time.\n\nISO 8601 formats\nA couple of the date formats from Date::Manip 5.xx conflicted with ISO 8601 formats in the\nspec. These are documented in the Date::Manip::Date documentation.\n\nDates are now parsed according to the spec (though a couple extensions have been made, which\nare also documented in the Date::Manip::Date documentation).\n\nThere is one change with respect to Date::Manip 5.xx that results from a possible\nmisinterpretation of the standard. In Date::Manip, there is a small amount of ambiguity in\nhow the Www-D date formats are understood.\n\nThe date:\n\n1996-w02-3\n\nmight be interpreted in two different ways. It could be interpreted as Wednesday (day 3) of\nthe 2nd week of 1996, or as the 3rd day of the 2nd week of 1996 (which would be Tuesday if\nthe week begins on Sunday). Since the specification only works with weeks which begin on day\n1, the two are always equivalent in the specification, and the language of the specification\ndoesn't clearly indicate one interpretation over the other.\n\nSince Date::Manip supports the concept of weeks starting on days other than day 1 (Monday),\nthe two interpretations are not equivalent.\n\nIn Date::Manip 5.xx, the date was interpreted as Wednesday of the 2nd week, but I now\nbelieve that the other interpretation (3rd day of the week) is the interpretation intended\nby the specification. In addition, if this interpretation is used, it is easy to get the\nother interpretation.\n\nIf 1996-w02-3 means the 3rd day of the 2nd week, then to get Wednesday (day 3) of the week,\nuse the following two Date::Manip::Date methods:\n\n$err   = $date->parse(\"1996-w02-1\");\n$date2 = $date->next(3,1);\n\nThe first call gets the 1st day of the 2nd week, and the second call gets the next\nWednesday.\n\nIf 1996-w02-3 is interpreted as Wednesday of the 2nd week, then to get the 3rd day of the\nweek involves significantly more work.\n\nIn Date::Manip 6.00, the date will now be parsed as the 3rd day of the 2nd week.\n\n(*) Parsing is now more rigid\nThe philosophy in Date::Manip 5.xx with respect to parsing dates was \"if there's any\nconceivable way to find a valid date in the string, do so\". As a result, strings which did\nnot look like they could contain a valid date often would.\n\nThis manifested itself it two ways. First, a lot of punctuation was ignored. For example,\nthe string \"01 // 03 -. 75\" was the date 1975-01-03.\n\nSecond, a lot of word breaks were optional and it was often acceptable to run strings\ntogether. For example, the delta \"in5seconds\" would have worked.\n\nWith Date::Manip 6.00, parsing now tries to find a valid date in the string, but uses a more\nrigidly defined set of allowed formats which should more closely match how the dates would\nactually be expressed in real life. The punctuation allowed is more rigidly defined, and\nword breaks are required. So \"01/03/75\" will work, but \"01//03/75\" and \"01/03-75\" won't.\nAlso, \"in5seconds\" will no longer work, though \"in 5 seconds\" will work.\n\nThese changes serve to simplify some of the regular expressions used in parsing dates, as\nwell as simplifying the parsing routines. They also help to recognize actually dates as\nopposed to typos... it was too easy to pass in garbage and get a date out.\n\nSupport dropped for a few formats\nI've dropped support for a few very uncommon (probably never used) formats. These include\n(with Jan 3, 2009 as an example):\n\nDD/YYmmm      03/09Jan\nDD/YYYYmmm    03/2009Jan\nmmmYYYY/DD    Jan2009/03\nYYYY/DDmmm    2009/03Jan\n\nmmmYYYY       Jan2009\nYYYYmmm       2009Jan\n\nThe last two are no longer supported since they are incomplete.\n\nWith the exception of the incomplete forms, these could be added back in with very little\neffort. If there is ever a request to do so, I probably will.\n\nNo longer parses the Apache format\nDate::Manip 5.xx supported the format:\n\nDD/mmm/YYYY:HH:MN:SS\n\nused in the apache logs. Due to the stricter parsing, this format is no longer supported\ndirectly. However, the parseformat method may be used to parse the date directly from an\napache log line with no need to extract the date string beforehand.\n\nDatePrevWorkDay behavior\nThe behavior of DatePrevWorkDay has changed slightly.\n\nThe starting date is checked. If $timecheck was non-zero, the check failed if the date was\nnot a business date, or if the time was not during business hours. If $timecheck was zero,\nthe check failed if the date was not a business date, but the time was ignored.\n\nIn 5.xx, if the check failed, and $timecheck was non-zero, day 0 was defined as the start of\nthe next business day, but if $timecheck was zero, day 0 was defined as the previous\nbusiness day at the same time.\n\nIn 6.xx, if the check fails, and $timecheck is non-zero, the behavior is the same as before.\nIf $timecheck is zero, day 0 is defined as the next business day at the same time.\n\nSo day 0 is now always the same, where before, day 0 meant two different things depending on\nwhether $timecheck was zero or not.\n\n(*) Default time\nIn Date::Manip 5.xx, the default times for dates was handled in an inconsistent manner. In\nthe Date::Manip::Date documentation, if you parse a date from the \"Common date formats\"\nsection, in Date::Manip 5.xx, if no time was included, it defaulted to \"00:00:00\". If you\nparsed a date from the \"Less common formats\" section, the default time was the current time.\n\nSo running a program on Jun 5, 2009 at noon that parsed the following dates gave the\nfollowing return values:\n\nJun 12     =>  Jun 12, 2009 at 00:00:00\nnext week  =>  Jun 12, 2009 at 12:00:00\n\nThis behavior is changed and now relies on the config variable DefaultTime. If DefaultTime\nis \"curr\", the default time for any date which includes no information about the time is the\ncurrent time. Otherwise, the default time is midnight.\n\n%z format\nIn Date::Manip 5.xx, the %z format would give an offset in the form: -0500. Now it gives it\nin the form: -05:00:00\n",
            "subsections": []
        },
        "DELTAS": {
            "content": "Dropped mixed style delta parsing\nIn Date::Manip 5.xx, a parsed delta could be written in the delta style\n\n1:2:3\n\nor in a language-specific expanded form:\n\n1 hour 2 minutes 3 seconds\n\nor in a mixed form:\n\n1 hour 2:3\n\nThe mixed form has been dropped since I doubt that it sees much use in real life, and by\ndropping the mixed form, the parsing is much simpler.\n\nApproximate date/date calculations\nIn Date::Manip 5.xx, the approximate delta between the two dates:\n\nJan 10 1996 noon\nJan  7 1998 noon\n\nwas +1:11:4:0:0:0:0 (or 1 year, 11 months, 4 weeks). As of Date::Manip 6.00, the delta is\n+2:0:-0:3:0:0:0 (or 2 years minus 3 days). Although this leads to mixed-sign deltas, it is\nactually how more people would think about the delta. It has the additional advantage of\nbeing MUCH easier and faster to calculate.\n\nApproximate relationships in deltas\nWhen printing parts of deltas in Date::Manip::5.xx, the approximate relationship of 1 year =\n365.25 days was used. This is the correct value for the Julian calendar, but for the\nGregorian calendar, a better value is 365.2425, and this is used in version 6.00.\n\nOld style formats\nThe formats used in the printf command are slightly different than in the old DeltaFormat\ncommand.\n\nThe old formats are described in the Date::Manip::DM5 manual, and the new ones are in the\nDate::Manip::Delta manual.\n\nThe new formats are much more flexible and I encourage you to switch over, however at this\npoint, the old style formats are officially supported for the DeltaFormat command.\n\nAt some point, the old style formats may be deprecated (and removed at some point beyond\nthat), but for now, they are not.\n\nThe old formats are NOT available using the printf method.\n",
            "subsections": []
        },
        "RECURRENCES": {
            "content": "The day field meaning changed in a few recurrences\nThe value of the day field can refer to several different things including the day of week\nnumber (Monday=1 to Sunday=7), day of month (1-31), day of year (1-366), etc.\n\nIn Date::Manip 5.xx, it could also refer to the nth day of the week (i.e. 1 being the 1st\nday of the week, -1 being the last day of the week). This meaning is no longer used in 6.xx.\n\nFor example, the recurrence:\n\n1*2:3:4:0:0:0\n\nreferred to the 3rd occurrence of the 4th day of the week in February.\n\nThe meaning has been changed to refer to the 3rd occurrence of day 4 (Thursday) in February.\nThis is a much more useful type of recurrence.\n\nAs a result of this change, the related recurrence:\n\n1*2:3:-1:0:0:0\n\nis invalid. Negative numbers may be used to refer to the nth day of the week, but NOT when\nreferring to the day of week numbers.\n\nRecurrence range now inclusive\nPreviously, the list of dates implied by the recurrence were on or after the start date, but\nbefore the end date.\n\nThis has been changed so that the dates may be on or before the end date.\n\nDropped support for a couple English recurrences\nDate::Manip 5.xx claimed support for a recurrence:\n\nevery 2nd day in June [1997]\n\nIn actuality, this recurrence is not practical to calculate. It requires a base date which\nmight imply June 1,3,5,... in 1997 but June 2,4,6 in 1998.\n\nIn addition, the recurrence does not fit the mold for other recurrences that are an\napproximate distance apart. This type of recurrence has a number of closely spaced events\nwith 11-month gaps between groups.\n\nI no longer consider this a valid recurrence and support is now dropped for this string.\n\nI also dropped the following for a similar reason:\n\nevery 6th Tuesday [in 1999]\n\nOther minor recurrence changes\nPreviously, ParseRecur would supply default dates if the start or end were missing. This is\nno longer done.\n\nDATE::MANIP FUNCTIONS\nThe Date::Manip module contains the same functions that Date::Manip 5.xx had (though the OO\nmodules do all the work now). In general, the routines behave the same as before with the\nfollowing exceptions:\n\nDateConvTZ\nPreviously, DateConvTZ took 1 to 4 arguments and used the local time zone and the ConvTZ\nconfig variable to fill in missing arguments.\n\nNow, the DateConvTZ function only supports a 3 argument call:\n\n$date = DateConvTZ($date,$from,$to);\n\nIf $from is not given, it defaults to the local time zone. If $to is not given, it defaults\nto the local time zone.\n\nThe optional 4th argument ($errlevel) is no longer supported. If there is an error, an empty\nstring is returned.\n\nDateCalc\nIn Date::Manip 5.xx, it was recommended that you pass arguments to ParseDate or\nParseDateDelta. This is not recommended with 6.00 since it is much more intelligent about\nhandling the arguments, and you'll just end up parsing the date/delta twice.\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::Changes5to6 - describes differences between 5.xx and 6.00",
    "flags": [],
    "examples": [],
    "see_also": []
}