{
    "mode": "perldoc",
    "parameter": "Date::Manip::Problems",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/perldoc/Date%3A%3AManip%3A%3AProblems/json",
    "generated": "2026-06-16T10:14:00Z",
    "sections": {
        "NAME": {
            "content": "Date::Manip::Problems - problems and bugs\n",
            "subsections": []
        },
        "KNOWN PROBLEMS": {
            "content": "The following are not bugs in Date::Manip, but they may give some people\nproblems.\n\nUnable to determine Time Zone\nIf you ever get the message that Date::Manip was unable to determine\nthe timezone, you need to provide that information to your script.\nPlease refer to the Date::Manip::TZ documentation for a discussion\nof this problem.\n\nCalculations appear to be off by an hour\nDue to daylight saving time (especially the spring change where the\ntime typically moves forward from 02:00 to 03:00), any date\ncalculation which would intuitively report a time in that range will\nalso move forward (or backward as the case may be).\n\n*NOTE* This should be less of a problem since 6.30 with the addition\nof semi-exact deltas.\n\nMissing date formats\nDue to the large number of date formats that Date::Manip CAN\nprocess, people often assume that other formats that they want to\nuse should work as well, and when they don't, it comes as a\nsurprise.\n\nWith the much improved parsing of 6.00, many formats can be added\neasily, though unless they are of general use, I'll probably suggest\nthat you use parseformat instead.\n\nThere is a class of formats that I do not plan to add however.\n\nI have frequently been asked to add formats such as \"the 15th of\nlast month\", or \"Monday of next week\". I do not intend to add these\ndate formats to Date::Manip, but since I have received the request\nseveral times, I decided to include my reasoning here.\n\nDate::Manip can parse pretty much any static date format that I\ncould think of or find reference to. Dates such as \"today\", \"Jan\n12\", or \"2001-01-01\" are all understood.\n\nThese are fairly limited however. Many very common date formats are\nbest thought of as a date plus a modification. For example,\n\"yesterday\" is actually determined internally as \"today\" plus a\nmodification of \"- 1 day\". \"2nd Sunday in June\" is determined as\n\"June 1\" modified to the 2nd Sunday.\n\nAs these types of formats were added over time, I quickly realized\nthat the number of possible date plus modification formats was huge.\nThe number of combinations has caused the parsing in Date::Manip to\nbe quite complex, and adding new formats occasionally causes\nunexpected conflicts with other formats.\n\nThe first time I received a request similar to \"the 15th of last\nmonth\", I intended to add it, but as I analyzed it to see what\nchanges needed to be made to support it, I realized that this needed\nto be expressed as a date plus TWO modifications. In other words,\ntoday modified to last month modified to the 15th day of the month.\n\nAs bad as date plus modification formats are, a date plus TWO\nmodifications would be exponentially worse. On realizing that, I\ndecided that Date::Manip will not support this type of format.\n\nAlthough I apologize for the inconvenience, I do not intend to\nchange my position on this.\n\nDate::Manip is slow\nDate::Manip is one of the slower Date/Time modules due to the fact\nthat it is huge and written entirely in perl. I have done a lot of\nwork optimizing it since 6.xx came out, and additional work is\nplanned, but even at it's best, it will probably be slower than\nother modules.\n\nSome things that will definitely help:\n\nDate::Manip 5.xx was very slow. A lot of work went into speeding it\nup as I rewrote it for the 6.xx release, and it should be noted that\ninitial tests show version 6.xx to be around twice as fast as 5.xx.\nThere is one notable exception to this speedup. If you use\nDate::Manip to parse dates from a wide variety of timezones, 6.xx\nwill be significantly slower than 5.xx. The reason for this is that\neach time a new timezone is accessed, 6.xx does quite a bit of work\nto initialize it. 5.xx does not have this overhead, so it can parse\ndates from any number of timezones without a speed penalty. However,\n5.xx does NOT handle timezones correctly, so many of the dates will\nbe incorrect. If timezones are important to you, there is no way to\nuse 5.xx and get accurate results.\n\nIf you only parse dates from a single timezone (which is more often\nwhat you are doing), 6.xx is significantly faster than 5.xx.\n\nISO-8601 dates are parsed first and fastest. If you have the\nflexibility to define the date format, use ISO-8601 formats whenever\npossible.\n\nAvoid parsing dates that are referenced against the current time (in\n2 days, today at noon, etc.). These take a lot longer to parse.\n\nBusiness date calculations are extremely slow. You should consider\nalternatives if possible (i.e. doing the calculation in exact mode\nand then multiplying by 5/7). Who needs a business date more\naccurate than \"6 to 8 weeks\" anyway, right :-)\n\nMemory leak\nThere is a known memory leak in perl related to named regexp\ncaptures that directly affects Date::Manip . The leak is in all\nversions of perl up to (and including) the following versions:\n\n5.10.1\n5.12.5\n5.14.3\n5.15.5\n\nThe bug has been fixed in:\n\n5.15.6\n5.16.0\n\nIf a maintenance release is done for any of the other releases\n(5.10, 5.12, 5.14), that includes the patch, I'll update this\nsection to include that information.\n\nDate::Manip 5.xx is not susceptible, so using it may be a feasible\nworkaround, but if you need accurate timezone handling, this isn't\npossible.\n\nSimple tests estimate the leak to be about 3 MB per 10,000 dates\nparsed, so unless you're parsing hundreds of thousands, or millions\nof dates, the leak probably won't be a problem on systems with\nmoderate amounts of memory. And if you're parsing that many dates,\nthe relatively slow Date::Manip may not be the correct module for\nyou to use anyway.\n\nDmake error on strawberry perl\nUsers of Strawberry perl on windows may encounter an error similar\nto the following:\n\ndmake: makefile: line 3016: Error: -- Input line too long, increase MAXLINELENGTH\n\nThis is a known problem with some versions of strawberry perl, and I\ncan't fix it in Date::Manip. If you encounter this problem, you can\ninstall the package manually using the commands:\n\nc:> cpan\ncpan> look Date::Manip::Date\n> perl Makefile.PL\n> dmake MAXLINELENGTH=300000 make\n> dmake MAXLINELENGTH=300000 make test\n> dmake MAXLINELENGTH=300000 make install\n\nYou can find more details here:\n\nhttp://www.nntp.perl.org/group/perl.win32.vanilla/2011/02/msg287.html\n\nUsing functions/methods which are not supported\nThere have been a handful of incidents of people using a function\nfrom Date::Manip which were not documented in the manual.\n\nDate::Manip consists of a large number of user functions which are\ndocumented in the manual. These are designed to be used by other\nprogrammers, and I will not make any backwards incompatible changes\nin them unless there is a very compelling reason to do so, and in\nthat case, the change will be clearly documented in the\nDate::Manip::Changes6 documentation for this module.\n\nDate::Manip also includes a large number of functions which are NOT\ndocumented. These are for internal use only. Please do not use them!\nI can (and do) change their functionality, and even their name,\nwithout notice, and without apology! Some of these internal\nfunctions even have test scripts, but that is not a guarantee that\nthey will not change, nor is any support implied. I simply like to\nrun regression tests on as much of Date::Manip as possible.\n\nAs of the most recent versions of Date::Manip, all internal\nfunctions have names that begin with an underscore (). If you\nchoose to use them directly, it is quite possible that new versions\nof Date::Manip will cause your programs to break due to a change in\nhow those functions work.\n\nAny changes to internal functions will not be documented, and will\nnot be regarded by me as a backwards incompatibility. Nor will I (as\nwas requested in one instance) revert to a previous version of the\ninternal function.\n\nIf you feel that an internal function is of more general use, feel\nfree to contact me with an argument of why it should be \"promoted\".\nI welcome suggestions and will definitely consider any such request.\n\nRCS Control\nIf you try to put Date::Manip under RCS control, you are going to\nhave problems. Apparently, RCS replaces strings of the form\n\"$Date...$\" with the current date. This form occurs all over in\nDate::Manip. To prevent the RCS keyword expansion, checkout files\nusing:\n\nco -ko\n\nSince very few people will ever have a desire to do this (and I\ndon't use RCS), I have not worried about it, and I do not intend to\ntry to workaround this problem.\n",
            "subsections": []
        },
        "KNOWN COMPLAINTS": {
            "content": "Date::Manip 6.xx has gotten some complaints (far more than 5.xx if the\ntruth be told), so I'd like to address a couple of them here. Perhaps an\nunderstanding of why some of the changes were made will allay some of\nthe complaints. If not, people are always welcome to stick with the 5.xx\nrelease. I will continue to support the 5.xx releases for a couple years\n(though I do NOT plan to add functionality to it).\n\nThese complaints come both from both the CPAN ratings site:\n\nhttp://cpanratings.perl.org/dist/Date-Manip\n\nand from personal email.\n\nRequires perl 5.10\nThe single most controversial change made in 6.00 is that it now\nrequired perl 5.10.0 or higher. Most of the negative feedback I've\nreceived is due to this.\n\nIn the past, I've avoided using new features of perl in order to\nallow Date::Manip to run on older versions of perl. Prior to perl\n5.10, none of the new features would have had a major impact on how\nDate::Manip was written so this practice was justified. That all\nchanged with the release of perl 5.10.\n\nOne of the aspects of Date::Manip that has received the most\npositive response is the ability to parse almost every conceivable\ndate format. Unfortunately, as I've added formats, the parsing\nroutine became more and more complicated, and maintaining it was one\nof the least enjoyable aspect in maintaining Date::Manip . In fact,\nfor several years I'd been extremely reluctant to add new formats\ndue to the fact that too often, adding a new format broke other\nformats.\n\nAs I was rewriting Date::Manip, I was looking for ways to improve\nthe parsing and to make maintaining it easier. Perl 5.10 provides\nthe feature \"named capture buffers\". Named capture buffers not only\nimproves the ease of maintaining the complex regular expressions\nused by Date::Manip, it makes it dramatically easier to add\nadditional formats in a way that is much less likely to interfere\nwith other formats. The parsing in 6.00 is so much more robust,\nextensible, and flexible, that it will make parser maintenance\npossible for many years to come at a fraction of the effort and\nrisk.\n\nIt was too much to turn down. Hopefully, since 5.10 has been out for\nsome time now, this will not prohibit too many people from using the\nnew version of Date::Manip. I realize that there are many people out\nthere using older versions of perl who do not have the option of\nupgrading perl. The decision to use 5.10 wasn't made lightly... but\nI don't regret making it. I apologize to users who, as a result,\ncannot use 6.00 . Hopefully in the future you'll be able to benefit\nfrom the improvements in 6.00.\n\nOne complaint I've received is that this in some way makes\nDate::Manip backwards incompatible, but this is not an accurate\ncomplaint. Version 6.xx DOES include some backwards\nincompatibilities (and these are covered in the\nDate::Manip::Migration5to6 document), however in almost all cases,\nthese incompatibilities are with infrequently used features, or\nworkarounds are in place to allow deprecated features to continue\nfunctioning for some period of time.\n\nThough I have no data to confirm this, I suspect that 90% or more of\nall scripts which were written with Date::Manip 5.xx will continue\nto work unmodified with 6.xx (of course, you should still refer to\nthe migration document to see what features are deprecated or\nchanged to make sure that you don't need to modify your script so\nthat it will continue to work in the future). Even with scripts that\nneed to be changed, the changes should be trivial.\n\nSo, Date::Manip 6.xx is almost entirely backward compatible with\n5.xx (to the extent that you would expect any major version release\nto be compatible with a previous major version).\n\nThe change is only in the requirements necessary to get Date::Manip\n6.xx to run.\n\nObviously, it's not reasonable to say that Date::Manip should never\nbe allowed to switch minimum perl versions. At some point, you have\nto let go of an old version if you want to make use of the features\nof the newer version. The question is, did I jump to 5.10 too fast?\n\nThe negative ratings I see in the CPAN ratings complain that I no\nlonger support perl 5.6 and perl 5.8.\n\nWith respect to 5.6, perl 5.6 was released in March of 2000 (that's\nbefore Windows XP which was released in 2001). Date::Manip 6.00 was\nreleased at the end of 2009. To be honest, I don't really feel much\nsympathy for this complaint. Software that is 9 years old is\nANCIENT. People may choose to use it... but please don't complain\nwhen new software comes out that doesn't support it.\n\nThe argument for perl 5.8 is much more compelling. Although 5.8 was\nreleased well before Date::Manip 6.00 (July of 2002), there were no\nmajor perl releases until 5.10 came out in December of 2007, so 5.8\nwas state-of-the art as little as 2 years prior to the release of\nDate::Manip 6.xx.\n\nI agree completely with the argument that abandoning 5.8 only 2\nyears after it was the current version is too soon. For that reason,\nI continued to support the Date::Manip 5.xx releases for several\nyears. As of December 2012 (5 years after the release of perl 5.10),\nthe 5.xx release is no longer supported (in that I will not patch it\nor provide support for it's use). However, it is still bundled into\nthe Date::Manip distribution so it can still be used. I do not have\nany plans for removing it, though I may do so at some point.\n\nToo many modules\nOne minor complaint is that there are too many files. One person\nspecifically objects to the fact that there are over 470 modules\ncovering non-minute offsets. This complaint is (IMO) silly.\n\nDate::Manip supports ALL historical time zones, including those with\nnon-minute offsets, and so there will be information for those time\nzones, even though they are not currently in use.\n\nI could of course store all of the information in one big module,\nbut that means that you have to load all of that data every time you\nuse Date::Manip, and I find that to be a very poor solution.\nInstead, storing the information in a per-time zone and per-offset\nmanner dramatically decreases the amount of data that has to be\nloaded.\n\nWhile it is true that Date::Manip includes over 900 modules for all\nof the time zone information, most implementations of time zone\nhandling also choose to break up the data into a large number of\nfiles.\n\nMy linux distribution (openSuSE 11.2 at the time of writing this)\nuses the standard zoneinfo database, and at this point, there are\nover 1700 files included in /usr/share/zoneinfo (though it does\nappear that there is some duplication of information). Current\nversions of RedHat also use over 1700 files, so Date::Manip isn't\ntreating the time zone data in a new or unreasonable way.\n\nObjects are large\nOne complaint that was put on the CPAN ratings site was that the OO\ninterface is \"a dud\" due to the size of it's objects. The complaint\nis that a Date::Manip::Date object is 115K while it should\n(according to the complaint) only require that you need to save the\nseconds from the epoch, zone, and a couple other pieces of\ninformation, all of which could probably be stored in 100 bytes or\nless.\n\nThis complaint is not accurate, and comes from a misunderstanding of\nthe objects used by Date::Manip.\n\nDate::Manip is very configurable, and contains a great deal of\ninformation which could theoretically be calculated on the fly, but\nwhich would greatly reduce it's performance. Instead, in the\ninterest of improving performance, the data is cached, and since the\ndata is virtually all potentially object specific, it has to be\nsomehow linked to the object.\n\nFor example, Date::Manip allows you to parse dates in several\nlanguages. Each language has a large number of regular expressions\nwhich are used to do the actual parsing. Instead of recreating these\nregular expressions each time they are needed, they are created once\nand stored in an object (specifically, a Date::Manip::Base object).\nThe size of the Date::Manip::Base object is almost 15K (due\nprimarily to the regular expressions used in parsing dates in the\nselected language).\n\nSimilarly, a description of the time zones are stored in a second\nobject (a Date::Manip::TZ object). The size of the Date::Manip::TZ\nobject starts at 100K. That may seem excessive, but you have to\nremember that there are almost 500 time zones, and they have to be\nindexed by name, alias, abbreviation, and offset. In addition,\ncritical dates (dates where the offset from GMT change such as\nduring a daylight saving time change) along with information such as\noffsets, abbreviation, etc., are all cached in order to improve\nperformance. By the time you do this, it does take a fair bit of\nspace. It should also be noted that the full description of each\ntimezone is only stored in the object when the timezone is actually\nused, so if you use a lot of timezones, this object will grow slowly\nas new timezones are used.\n\nThe size of the actual Date::Manip::Date object is a little over 300\nbytes. However, each includes a pointer to a Date::Manip::Base and a\nDate::Manip::TZ object (and due to how the object was being looked\nat in the complaint, they were reporting the size of all three\nobjects, NOT just the Date::Manip::Date object).\n\nBoth the Date::Manip::Base and Date::Manip::TZ objects are reused by\nany number of Date::Manip::Date objects. They can almost be thought\nof as global data, except that they are accessible in the standard\nOO manner, and you are allowed to modify them on a per-object basis\nwhich WILL mean that you have to store more data. If you work with\nmultiple configurations (see Date::Manip::Config), you'll need\nmultiple Base and TZ objects. However, most of the time you will not\nneed to do this.\n\nThe actual Date::Manip::Date object is a bit larger than suggested\nin the complaint, but it should be noted that Date::Manip actually\nstores the dates in a number of different formats (a string of the\nform YYYYMMDDHH:MN:SS and a list [YYYY,MM,DD,HH,MN,SS] in the time\nzone it was parsed in, the local time zone (if different) and GMT.\nBy caching this information as it is used, it has a huge impact on\nthe performance.\n\nSo, Date::Manip in typical usage consists of one 100K\nDate::Manip::TZ object, one 15K Date::Manip::Base objects, and any\nnumber of small 300 byte Date::Manip::Date objects.\nDate::Manip::Delta objects are even smaller. Date::Manip::Recur\nobjects are also small, but they contain any number of Date objects\nin them.\n\nI am certainly open to suggestions as to how I can improve the OO\ninterface... but I don't believe it is a dud. While I'm not an\nexpert at OO programming, I believe that I followed pretty standard\nand accepted procedures for accessing the data.\n\nPlease refer to the Date::Manip::Objects document for more\ninformation.\n\nDate::Manip has an inconsistent interface\nI've gotten a few complaints that the interface to Date::Manip is\ninconsistent... and I agree (at least when referring to the\nfunctional interfaces).\n\nDate::Manip was originally written in an unplanned way... as a\nneed/want came up, it was extended. That's not the way to write a\nmajor package of course, but it wasn't expected to be a major\npackage at the start.\n\nAs it became more and more widely used, I too wished for a more\nconsistent interface, but I did not want to break backward\ncompatibility for everyone using it.\n\nWhen 6.xx was written, I spent a good deal of time trying to make a\nvery standard OO interface, so I do not believe that this complaint\ncan be applied to the OO interface (though I'm interested in\nsuggestions for improving it of course).\n\nAs far as the functional interface goes, I'll continue to support it\nin a backward compatible (and therefore inconsistent) form. I'd\nencourage the use of the OO interface whenever possible.\n",
            "subsections": []
        },
        "BUGS AND QUESTIONS": {
            "content": "If you find a bug in Date::Manip, there are three ways to send it to me.\nIn order of preference, they are:\n\nGitHub\nYou can submit it as an issue on GitHub. This can be done at the\nfollowing URL:\n\n<https://github.com/SBECK-github/Date-Manip>\n\nThis is the preferred method. Please submit problems requests as\nGitHub issues if at all possible.\n\nDirect email\nYou are welcome to send it directly to me by email. The email\naddress to use is: sbeck@cpan.org.\n\nPlease note that because cpan.org addresses are published, they are\nused by a lot of spammers and phishers. Please include the name of\nthe perl module in the subject line of ALL messages sent to my\ncpan.org address or it will likely be missed.\n\nCPAN Bug Tracking\nYou can submit it using the CPAN tracking too. This can be done at\nthe following URL:\n\n<http://rt.cpan.org/Public/Dist/Display.html?Name=Date-Manip>\n\nThere was discussion of halting this service a while back (though it\ncontinues to function), so only use this as a last resort.\n\nPlease do not use other means to report bugs (such as forums for a\nspecific OS or Linux distribution) as it is impossible for me to keep up\nwith all of them.\n\nWhen filing a bug report, please include the following information:\n\nDate::Manip version\nPlease include the version of Date::Manip you are using. You can get\nthis by using the script:\n\nuse Date::Manip;\nprint DateManipVersion(1),\"\\n\";\n\nor\n\nuse Date::Manip::Date;\n$obj = new Date::Manip::Date;\nprint $obj->version(1),\"\\n\";\n\nPerl information\nPlease include the output from \"perl -V\"\n\nIf you have a problem using Date::Manip that perhaps isn't a bug (can't\nfigure out the syntax, etc.), you're in the right place. Start by\nreading the main Date::Manip documentation, and the other documents that\napply to whatever you are trying to do. If this still doesn't answer\nyour question, mail me directly.\n\nI would ask that you be reasonably familiar with the documentation\nBEFORE you choose to do this. Date::Manip is a hobby, and I simply do\nnot have time to respond to hundreds of questions which are already\nanswered in this manual.\n\nIf you find any problems with the documentation (errors, typos, or items\nthat are not clear), please send them to me. I welcome any suggestions\nthat will allow me to improve the documentation.\n",
            "subsections": []
        },
        "KNOWN BUGS": {
            "content": "None known.\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\nunder the same terms as Perl itself.\n",
            "subsections": []
        },
        "AUTHOR": {
            "content": "Sullivan Beck (sbeck@cpan.org)\n",
            "subsections": []
        }
    },
    "summary": "Date::Manip::Problems - problems and bugs",
    "flags": [],
    "examples": [],
    "see_also": []
}