{
    "mode": "perldoc",
    "parameter": "Date::Manip::Problems",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/perldoc/Date%3A%3AManip%3A%3AProblems/json",
    "generated": "2026-06-10T13:42:57Z",
    "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 problems.\n\nUnable to determine Time Zone\nIf you ever get the message that Date::Manip was unable to determine the timezone, you need\nto provide that information to your script. Please refer to the Date::Manip::TZ\ndocumentation for a discussion of this problem.\n\nCalculations appear to be off by an hour\nDue to daylight saving time (especially the spring change where the time typically moves\nforward from 02:00 to 03:00), any date calculation which would intuitively report a time in\nthat range will also 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 of semi-exact deltas.\n\nMissing date formats\nDue to the large number of date formats that Date::Manip CAN process, people often assume\nthat other formats that they want to use should work as well, and when they don't, it comes\nas a surprise.\n\nWith the much improved parsing of 6.00, many formats can be added easily, though unless they\nare of general use, I'll probably suggest that 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 last month\", or \"Monday of\nnext week\". I do not intend to add these date formats to Date::Manip, but since I have\nreceived the request several times, I decided to include my reasoning here.\n\nDate::Manip can parse pretty much any static date format that I could think of or find\nreference to. Dates such as \"today\", \"Jan 12\", or \"2001-01-01\" are all understood.\n\nThese are fairly limited however. Many very common date formats are best thought of as a\ndate plus a modification. For example, \"yesterday\" is actually determined internally as\n\"today\" plus a modification of \"- 1 day\". \"2nd Sunday in June\" is determined as \"June 1\"\nmodified to the 2nd Sunday.\n\nAs these types of formats were added over time, I quickly realized that the number of\npossible date plus modification formats was huge. The number of combinations has caused the\nparsing in Date::Manip to be 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 month\", I intended to add\nit, but as I analyzed it to see what changes needed to be made to support it, I realized\nthat this needed to be expressed as a date plus TWO modifications. In other words, today\nmodified to last month modified to the 15th day of the month.\n\nAs bad as date plus modification formats are, a date plus TWO modifications would be\nexponentially worse. On realizing that, I decided that Date::Manip will not support this\ntype of format.\n\nAlthough I apologize for the inconvenience, I do not intend to change my position on this.\n\nDate::Manip is slow\nDate::Manip is one of the slower Date/Time modules due to the fact that it is huge and\nwritten entirely in perl. I have done a lot of work optimizing it since 6.xx came out, and\nadditional work is planned, but even at it's best, it will probably be slower than other\nmodules.\n\nSome things that will definitely help:\n\nDate::Manip 5.xx was very slow. A lot of work went into speeding it up as I rewrote it for\nthe 6.xx release, and it should be noted that initial tests show version 6.xx to be around\ntwice as fast as 5.xx. There is one notable exception to this speedup. If you use\nDate::Manip to parse dates from a wide variety of timezones, 6.xx will be significantly\nslower than 5.xx. The reason for this is that each time a new timezone is accessed, 6.xx\ndoes quite a bit of work to initialize it. 5.xx does not have this overhead, so it can parse\ndates from any number of timezones without a speed penalty. However, 5.xx does NOT handle\ntimezones correctly, so many of the dates will be incorrect. If timezones are important to\nyou, there is no way to use 5.xx and get accurate results.\n\nIf you only parse dates from a single timezone (which is more often what you are doing),\n6.xx is significantly faster than 5.xx.\n\nISO-8601 dates are parsed first and fastest. If you have the flexibility to define the date\nformat, use ISO-8601 formats whenever possible.\n\nAvoid parsing dates that are referenced against the current time (in 2 days, today at noon,\netc.). These take a lot longer to parse.\n\nBusiness date calculations are extremely slow. You should consider alternatives if possible\n(i.e. doing the calculation in exact mode and then multiplying by 5/7). Who needs a business\ndate more accurate than \"6 to 8 weeks\" anyway, right :-)\n\nMemory leak\nThere is a known memory leak in perl related to named regexp captures that directly affects\nDate::Manip . The leak is in all versions of perl up to (and including) the following\nversions:\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 (5.10, 5.12, 5.14), that\nincludes the patch, I'll update this section to include that information.\n\nDate::Manip 5.xx is not susceptible, so using it may be a feasible workaround, but if you\nneed accurate timezone handling, this isn't possible.\n\nSimple tests estimate the leak to be about 3 MB per 10,000 dates parsed, so unless you're\nparsing hundreds of thousands, or millions of dates, the leak probably won't be a problem on\nsystems with moderate amounts of memory. And if you're parsing that many dates, the\nrelatively slow Date::Manip may not be the correct module for you to use anyway.\n\nDmake error on strawberry perl\nUsers of Strawberry perl on windows may encounter an error similar to 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 can't fix it in\nDate::Manip. If you encounter this problem, you can install the package manually using the\ncommands:\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 from Date::Manip which\nwere not documented in the manual.\n\nDate::Manip consists of a large number of user functions which are documented in the manual.\nThese are designed to be used by other programmers, and I will not make any backwards\nincompatible changes in them unless there is a very compelling reason to do so, and in that\ncase, the change will be clearly documented in the Date::Manip::Changes6 documentation for\nthis module.\n\nDate::Manip also includes a large number of functions which are NOT documented. These are\nfor internal use only. Please do not use them! I can (and do) change their functionality,\nand even their name, without notice, and without apology! Some of these internal functions\neven have test scripts, but that is not a guarantee that they will not change, nor is any\nsupport implied. I simply like to run regression tests on as much of Date::Manip as\npossible.\n\nAs of the most recent versions of Date::Manip, all internal functions have names that begin\nwith an underscore (). If you choose to use them directly, it is quite possible that new\nversions of Date::Manip will cause your programs to break due to a change in how those\nfunctions work.\n\nAny changes to internal functions will not be documented, and will not be regarded by me as\na backwards incompatibility. Nor will I (as was requested in one instance) revert to a\nprevious version of the internal function.\n\nIf you feel that an internal function is of more general use, feel free to contact me with\nan argument of why it should be \"promoted\". I welcome suggestions and will definitely\nconsider any such request.\n\nRCS Control\nIf you try to put Date::Manip under RCS control, you are going to have problems. Apparently,\nRCS replaces strings of the form \"$Date...$\" with the current date. This form occurs all\nover in Date::Manip. To prevent the RCS keyword expansion, checkout files using:\n\nco -ko\n\nSince very few people will ever have a desire to do this (and I don't use RCS), I have not\nworried about it, and I do not intend to try to workaround this problem.\n",
            "subsections": []
        },
        "KNOWN COMPLAINTS": {
            "content": "Date::Manip 6.xx has gotten some complaints (far more than 5.xx if the truth be told), so I'd\nlike to address a couple of them here. Perhaps an understanding of why some of the changes were\nmade will allay some of the 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 (though I do NOT plan\nto 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 required perl 5.10.0 or\nhigher. Most of the negative feedback I've received is due to this.\n\nIn the past, I've avoided using new features of perl in order to allow Date::Manip to run on\nolder versions of perl. Prior to perl 5.10, none of the new features would have had a major\nimpact on how Date::Manip was written so this practice was justified. That all changed with\nthe release of perl 5.10.\n\nOne of the aspects of Date::Manip that has received the most positive response is the\nability to parse almost every conceivable date format. Unfortunately, as I've added formats,\nthe parsing routine became more and more complicated, and maintaining it was one of the\nleast enjoyable aspect in maintaining Date::Manip . In fact, for several years I'd been\nextremely reluctant to add new formats due to the fact that too often, adding a new format\nbroke other formats.\n\nAs I was rewriting Date::Manip, I was looking for ways to improve the parsing and to make\nmaintaining it easier. Perl 5.10 provides the feature \"named capture buffers\". Named capture\nbuffers not only improves the ease of maintaining the complex regular expressions used by\nDate::Manip, it makes it dramatically easier to add additional formats in a way that is much\nless likely to interfere with other formats. The parsing in 6.00 is so much more robust,\nextensible, and flexible, that it will make parser maintenance possible for many years to\ncome at a fraction of the effort and risk.\n\nIt was too much to turn down. Hopefully, since 5.10 has been out for some time now, this\nwill not prohibit too many people from using the new version of Date::Manip. I realize that\nthere are many people out there 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 I don't regret making\nit. I apologize to users who, as a result, cannot use 6.00 . Hopefully in the future you'll\nbe able to benefit from the improvements in 6.00.\n\nOne complaint I've received is that this in some way makes Date::Manip backwards\nincompatible, but this is not an accurate complaint. Version 6.xx DOES include some\nbackwards incompatibilities (and these are covered in the Date::Manip::Migration5to6\ndocument), however in almost all cases, these incompatibilities are with infrequently used\nfeatures, or workarounds are in place to allow deprecated features to continue functioning\nfor some period of time.\n\nThough I have no data to confirm this, I suspect that 90% or more of all scripts which were\nwritten with Date::Manip 5.xx will continue to work unmodified with 6.xx (of course, you\nshould still refer to the migration document to see what features are deprecated or changed\nto make sure that you don't need to modify your script so that it will continue to work in\nthe future). Even with scripts that need to be changed, the changes should be trivial.\n\nSo, Date::Manip 6.xx is almost entirely backward compatible with 5.xx (to the extent that\nyou would expect any major version release to be compatible with a previous major version).\n\nThe change is only in the requirements necessary to get Date::Manip 6.xx to run.\n\nObviously, it's not reasonable to say that Date::Manip should never be allowed to switch\nminimum perl versions. At some point, you have to let go of an old version if you want to\nmake use of the features of 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 longer support perl 5.6\nand perl 5.8.\n\nWith respect to 5.6, perl 5.6 was released in March of 2000 (that's before Windows XP which\nwas released in 2001). Date::Manip 6.00 was released at the end of 2009. To be honest, I\ndon't really feel much sympathy for this complaint. Software that is 9 years old is ANCIENT.\nPeople may choose to use it... but please don't complain when new software comes out that\ndoesn't support it.\n\nThe argument for perl 5.8 is much more compelling. Although 5.8 was released well before\nDate::Manip 6.00 (July of 2002), there were no major perl releases until 5.10 came out in\nDecember of 2007, so 5.8 was 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 years after it was the\ncurrent version is too soon. For that reason, I continued to support the Date::Manip 5.xx\nreleases for several years. 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 or provide support for\nit's use). However, it is still bundled into the Date::Manip distribution so it can still be\nused. I do not have any 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 specifically objects to the\nfact that there are over 470 modules covering non-minute offsets. This complaint is (IMO)\nsilly.\n\nDate::Manip supports ALL historical time zones, including those with non-minute offsets, and\nso there will be information for those time zones, even though they are not currently in\nuse.\n\nI could of course store all of the information in one big module, but that means that you\nhave to load all of that data every time you use Date::Manip, and I find that to be a very\npoor solution. Instead, storing the information in a per-time zone and per-offset manner\ndramatically decreases the amount of data that has to be loaded.\n\nWhile it is true that Date::Manip includes over 900 modules for all of the time zone\ninformation, most implementations of time zone handling also choose to break up the data\ninto a large number of files.\n\nMy linux distribution (openSuSE 11.2 at the time of writing this) uses the standard zoneinfo\ndatabase, and at this point, there are over 1700 files included in /usr/share/zoneinfo\n(though it does appear that there is some duplication of information). Current versions of\nRedHat also use over 1700 files, so Date::Manip isn't treating the time zone data in a new\nor unreasonable way.\n\nObjects are large\nOne complaint that was put on the CPAN ratings site was that the OO interface is \"a dud\" due\nto the size of it's objects. The complaint is that a Date::Manip::Date object is 115K while\nit should (according to the complaint) only require that you need to save the seconds from\nthe epoch, zone, and a couple other pieces of information, all of which could probably be\nstored in 100 bytes or less.\n\nThis complaint is not accurate, and comes from a misunderstanding of the objects used by\nDate::Manip.\n\nDate::Manip is very configurable, and contains a great deal of information which could\ntheoretically be calculated on the fly, but which would greatly reduce it's performance.\nInstead, in the interest of improving performance, the data is cached, and since the data is\nvirtually all potentially object specific, it has to be somehow linked to the object.\n\nFor example, Date::Manip allows you to parse dates in several languages. Each language has a\nlarge number of regular expressions which are used to do the actual parsing. Instead of\nrecreating these regular expressions each time they are needed, they are created once and\nstored in an object (specifically, a Date::Manip::Base object). The size of the\nDate::Manip::Base object is almost 15K (due primarily to the regular expressions used in\nparsing dates in the selected language).\n\nSimilarly, a description of the time zones are stored in a second object (a Date::Manip::TZ\nobject). The size of the Date::Manip::TZ object starts at 100K. That may seem excessive, but\nyou have to remember that there are almost 500 time zones, and they have to be indexed by\nname, alias, abbreviation, and offset. In addition, critical dates (dates where the offset\nfrom GMT change such as during a daylight saving time change) along with information such as\noffsets, abbreviation, etc., are all cached in order to improve performance. By the time you\ndo this, it does take a fair bit of space. It should also be noted that the full description\nof each timezone is only stored in the object when the timezone is actually used, so if you\nuse a lot of timezones, this object will grow slowly as new timezones are used.\n\nThe size of the actual Date::Manip::Date object is a little over 300 bytes. However, each\nincludes a pointer to a Date::Manip::Base and a Date::Manip::TZ object (and due to how the\nobject was being looked at 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 any number of\nDate::Manip::Date objects. They can almost be thought of as global data, except that they\nare accessible in the standard OO manner, and you are allowed to modify them on a per-object\nbasis which WILL mean that you have to store more data. If you work with multiple\nconfigurations (see Date::Manip::Config), you'll need multiple Base and TZ objects. However,\nmost of the time you will not need to do this.\n\nThe actual Date::Manip::Date object is a bit larger than suggested in the complaint, but it\nshould be noted that Date::Manip actually stores the dates in a number of different formats\n(a string of the form YYYYMMDDHH:MN:SS and a list [YYYY,MM,DD,HH,MN,SS] in the time zone it\nwas parsed in, the local time zone (if different) and GMT. By caching this information as it\nis used, it has a huge impact on the performance.\n\nSo, Date::Manip in typical usage consists of one 100K Date::Manip::TZ object, one 15K\nDate::Manip::Base objects, and any number of small 300 byte Date::Manip::Date objects.\nDate::Manip::Delta objects are even smaller. Date::Manip::Recur objects are also small, but\nthey contain any number of Date objects in them.\n\nI am certainly open to suggestions as to how I can improve the OO interface... but I don't\nbelieve it is a dud. While I'm not an expert at OO programming, I believe that I followed\npretty standard and accepted procedures for accessing the data.\n\nPlease refer to the Date::Manip::Objects document for more information.\n\nDate::Manip has an inconsistent interface\nI've gotten a few complaints that the interface to Date::Manip is inconsistent... and I\nagree (at least when referring to the functional interfaces).\n\nDate::Manip was originally written in an unplanned way... as a need/want came up, it was\nextended. That's not the way to write a major package of course, but it wasn't expected to\nbe a major package at the start.\n\nAs it became more and more widely used, I too wished for a more consistent interface, but I\ndid not want to break backward compatibility for everyone using it.\n\nWhen 6.xx was written, I spent a good deal of time trying to make a very standard OO\ninterface, so I do not believe that this complaint can be applied to the OO interface\n(though I'm interested in suggestions for improving it of course).\n\nAs far as the functional interface goes, I'll continue to support it in a backward\ncompatible (and therefore inconsistent) form. I'd encourage the use of the OO interface\nwhenever possible.\n",
            "subsections": []
        },
        "BUGS AND QUESTIONS": {
            "content": "If you find a bug in Date::Manip, there are three ways to send it to me. In order of preference,\nthey are:\n\nGitHub\nYou can submit it as an issue on GitHub. This can be done at the following URL:\n\n<https://github.com/SBECK-github/Date-Manip>\n\nThis is the preferred method. Please submit problems requests as GitHub issues if at all\npossible.\n\nDirect email\nYou are welcome to send it directly to me by email. The email address to use is:\nsbeck@cpan.org.\n\nPlease note that because cpan.org addresses are published, they are used by a lot of\nspammers and phishers. Please include the name of the perl module in the subject line of ALL\nmessages sent to my cpan.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 the 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 continues to function),\nso only use this as a last resort.\n\nPlease do not use other means to report bugs (such as forums for a specific OS or Linux\ndistribution) as it is impossible for me to keep up with 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 this by using the\nscript:\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 figure out the syntax,\netc.), you're in the right place. Start by reading the main Date::Manip documentation, and the\nother documents that apply to whatever you are trying to do. If this still doesn't answer your\nquestion, mail me directly.\n\nI would ask that you be reasonably familiar with the documentation BEFORE you choose to do this.\nDate::Manip is a hobby, and I simply do not have time to respond to hundreds of questions which\nare already answered in this manual.\n\nIf you find any problems with the documentation (errors, typos, or items that are not clear),\nplease send them to me. I welcome any suggestions that will allow me to improve the\ndocumentation.\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 under the same terms as\nPerl itself.\n",
            "subsections": []
        },
        "AUTHOR": {
            "content": "Sullivan Beck (sbeck@cpan.org)\n",
            "subsections": []
        }
    },
    "summary": "Date::Manip::Problems - problems and bugs",
    "flags": [],
    "examples": [],
    "see_also": []
}