{
    "mode": "perldoc",
    "parameter": "Date::Manip::Misc",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/perldoc/Date%3A%3AManip%3A%3AMisc/json",
    "generated": "2026-06-12T06:42:53Z",
    "sections": {
        "NAME": {
            "content": "Date::Manip::Misc - Miscellaneous information about Date::Manip\n\nSHOULD I USE DATE::MANIP\nIf you look in CPAN, you'll find that there are a number of Date and Time packages. Is\nDate::Manip the one you should be using? That isn't a trivial question to answer. It depends to\na large extent on what you are trying to do.\n\nDate::Manip is certainly one of the most powerful of the Date modules (the other main contender\nbeing the DateTime suite of modules). I'm trying to build a library which can do EVERY\nconceivable date/time manipulation that you'll run into in everyday life dealing with the\nGregorian calendar. To the best of my knowledge, it will do everything that any other date\nmodule will do which work with the Gregorian calendar, and there are a number of features that\nDate::Manip has that other modules do not have.\n\nThere is a tradeoff in being able to do \"everything\"... and that tradeoff is primarily in terms\nof performance. Date::Manip is written entirely in Perl and is the largest of the date modules.\nOther modules tend to be faster than Date::Manip, and modules written in C are significantly\nfaster than their Perl counterparts (at least if they're done right). Although I am working on\nmaking Date::Manip faster, it will never be as fast as other modules. And before anyone asks,\nDate::Manip will never be translated to C (at least by me). I write C because I have to. I write\nPerl because I like to. Date::Manip is something I do because it interests me, not something I'm\npaid for.\n\nIf you are going to be using the module in cases where performance is an important factor, and\nyou're doing a fairly small set of simple date operations over and over again, you should\ncarefully examine the other date modules to see if they will meet your needs.\n\nDate::Manip does NOT provide functionality for working with alternate calendars such as the\nChinese or Hebrew calendars, so if you need that functionality, you definitely need to look\nelsewhere (the DateTime suite probably).\n\nOn the other hand, if you want one solution for all your date needs, don't need peak speed, or\nare trying to do more exotic date operations, Date::Manip is for you. Operations on things like\nbusiness dates, foreign language dates, holidays and other recurring events, complete timezone\nhandling, etc. are available more-or-less exclusively in Date::Manip. At the very least, if you\nwant to be able to do these operations, it will require using several other modules, each with\nit's own interface. Also, when you work with Date::Manip, you work with one author and one\nmodule. The DateTime suite currently consists of almost 100 modules and 75 authors.\n\nIn addition, I am making significant performance improvements in Date::Manip. Although it will\nnever be as fast as some of the other perl modules, I believe that it is already competitive\nenough for most purposes, and I continue to look for places where I can improve performance, so\nperformance should improve over time.\n",
            "subsections": []
        },
        "YEAR 2000 AND YEAR 2007 DST CHANGE": {
            "content": "Did Date::Manip have any problems with Y2K compliance? Did it have any problems with the revised\ndaylight saving time changes made in 2007?\n\nAlthough Date::Manip will parse many date strings (including dates with 2-digit years),\ninternally they are stored as a 4 digit year, and all operations are performed using this\ninternal representation, so Date::Manip had no problems with the Y2K issue. Of course,\napplications written which stored the year as 2 digits (whether or not it used Date::Manip) may\nhave had problems, but they were not because of this module.\n\nSimilarly for the 2007 changes in daylight saving time made in the United States, Date::Manip\nwas not affected. Date::Manip makes use of the current time zone, but it gets that information\nfrom the operating system the application is running on. If the operating system knows about the\nnew daylight saving time rules... so does Date::Manip.\n\nWHAT DATES ARE DATE::MANIP USEFUL FOR?\nDate::Manip applies to the Gregorian calendar. It does not support alternative calendars\n(Hebrew, Mayan, etc.) so if you want to use an alternative calendar, you'll need to look\nelsewhere.\n\nThe Gregorian calendar is a relatively recent innovation. Prior to it, the Julian calendar was\nin use. The Julian calendar defined leap years as every 4th year. This led to significant\ncalendar drift over time (since a year is NOT 365.25 days long). It was replaced by the\nGregorian calendar which improved the definition of leap years, and at that point, the calendar\nwas adjusted appropriately.\n\nDate::Manip extrapolates the Gregorian calendar back to the year 0001 AD and forward to the year\n9999 AD, but that does not necessarily mean that the results are useful. As the world adopted\nthe Gregorian calendar, the dates using the Julian calendar had to be changed to fit to account\nfor the drift that had occurred. As such, the dates produced by Date::Manip in an era where the\nJulian calendar was in use do not accurately reflect the dates actually in use. In historical\ncontext, the Julian calendar was in use until 1582 when the Gregorian calendar was adopted by\nthe Catholic church. Protestant countries did not accept it until later; Germany and Netherlands\nin 1698, British Empire in 1752, Russia in 1918, etc. Date::Manip is therefore not equipped to\ntruly deal with historical dates prior to about 1600, and between 1600 and 1900, the calendar\nvaried from country to country.\n\nA second problem is that the Gregorian calendar is itself imperfect and at some point may need\nto be corrected (though it's not clear that this will happen... drift may now be accounted for\nusing leap seconds which means that the Gregorian calendar may be useful indefinitely). No\nattempt is made to correct for the problems in the Gregorian calendar for a couple reasons.\nFirst is that my great great great grandchildren will be long dead before this begins to be a\nproblem, so it's not an immediate concern. Secondly, and even more importantly, I don't know\nwhat the correction will be (if any) or when it will be implemented, so I can safely ignore it.\n\nThere is some limitation on how dates can be expressed such that Date::Manip can handle them\ncorrectly. Date::Manip stores the year internally as a 4-digit number. This is obviously not a\nlimit due to the Gregorian calendar, but I needed a way to store the dates internally, and the\n4-digit year was chosen. I realize that the 4-digit limitation does create a time when it will\nbreak (quite similar to those who chose a 2-digit representation set themselves up for the Y2K\nproblem). Frankly, I'm not too concerned about this since that date is 8000 years in the future!\nDate::Manip won't exist then. Perl won't exist then. And it's quite possible that the Gregorian\ncalendar won't exist then. That's a much different situation than the Y2K choice in which\nprogrammers chose a representation that would break within the lifetime of the programs they\nwere writing.\n\nGiven the 4-digit limitation, Date::Manip definitely can't handle BC dates, or dates past Dec\n31, 9999. So Date::Manip works (in theory) during the period Jan 1, 0001 to Dec 31, 9999. There\nare a few caveats:\n\nGregorian calendar issue\nIn practical terms, Date::Manip deals with the Gregorian calendar, and is most useful in the\nperiod that that calendar has been, or will be, in effect. As explained above, the Gregorian\ncalendar came into universal acceptance in the early 1900's, and it should remain in use for\nthe foreseeable future.\n\nSo... in practical terms, Date::Manip is probably useful from around 1900 through several\nthousand years from now.\n\nFirst/last week\nIn one part of the code (calculating week-of-year values), Date::Manip references dates one\nweek after and one week before the date actually being worked on. As such, dates during the\nfirst week in the year 0001 fail (because a week before is in the year 1 BC), and those in\nthe last week in the year 9999 fail (because a week later is in 10,000).\n\nNo effort will be made to correct this because the added functionality is simply not that\nimportant (to me), especially since the Gregorian calendar doesn't really apply in either\ninstance. To be absolutely safe, I will state that Date::Manip works as described in this\nmanual during the period Feb 1, 0001 to Nov 30, 9999, and I will only support dates within\nthat range (i.e. if you submit a bug using a date that is not in that range, I will will\nconsider myself free to ignore it).\n\nLeap seconds\nDate::Manip does NOT make use of the leap seconds in calculating time intervals, so the\ndifference between two times may not be strictly accurate due to the addition of a leap\nsecond.\n\nThree-digit years\nDate::Manip will parse both 2- and 4-digit years, but it will NOT handle 3 digit years. So,\nif you store the year as an offset from 1900 (which is 3 digits long as of the year 2000),\nthese will NOT be parseable by Date::Manip. Since the perl functions localtime and gmtime DO\nreturn the year as an offset from 1900, the output from these will need to be corrected\n(probably by adding 1900 to the result) before they can be passed to any Date::Manip\nroutine.\n",
            "subsections": []
        },
        "FUTURE IDEAS": {
            "content": "A number of changes are being considered for future inclusion in Date::Manip. As a rule, the\nchanges listed below are not finalized, and are open to discussion.\n\nRewrite parsing for better language support\nCurrently, all of Date::Manip's parsing is based on English language forms of dates, even if\nthe words have been replaced by the equivalent in some other language.\n\nI am considering rewriting the parsing routines in order to allow date forms that might be\nused in other languages but do not have a common English equivalent, and to account for the\nfact that some English formats may not have an equivalent in another language.\n\nAdding granularity\nThe granularity of a time basically refers to how accurate you wish to treat a date. For\nexample, if you want to compare two dates to see if they are identical at a granularity of\ndays, then they only have to occur on the same day. At a granularity of an hour, they have\nto occur within an hour of each other, etc.\n\nI'm not sure how useful this would be, but it's one of the oldest unimplemented ideas, so\nI'm not discarding it completely.\n",
            "subsections": []
        },
        "ACKNOWLEDGMENTS": {
            "content": "There are many people who have contributed to Date::Manip over the years that I'd like to thank.\nThe most important contributions have come in the form of suggestions and bug reports by users.\nI have tried to include the name of every person who first suggested each improvement or first\nreported each bug. These are included in the Date::Manip::Changes5 and Date::Manip::Changes6\ndocuments. The list is simply too long to appear here, but I appreciate their help.\n\nA number of people have made suggestions or reported bugs which are not mentioned in these\ndocuments. These include suggestions which have not been implemented and people who have made a\nsuggestion or bug report which has already been suggested/reported by someone else. For those\nwho's suggestions have not yet been implemented, they will be added to the appropriate Changes\ndocument when (if) their suggestions are implemented. I keep every single suggestion I've ever\nreceived and periodically review the unimplemented ones to see if it's something I'm interested\nin, so even suggestions made years in the past may still appear in future versions of\nDate::Manip, and the original requester will be attributed at that point (some of the changes\nmade to Date::Manip 6.00 were based on suggestions 10 years old which never fit in with version\n5.xx, but which I knew I wanted to implement). For those who have sent in requests/reports that\nhad been previously made by someone else, thank you too. I'd much rather have a suggestion made\ntwice than not at all.\n\nThanks to Alan Cezar and Greg Schiedler for paying me to implement the EventsList routine. They\ngave me the idea, and were then willing to pay me for my time to get it implemented quickly.\n\nI'd also like to thank a couple of authors. Date::Manip has gotten some really good press in a\ncouple of books. Since no one's paying me to write Date::Manip, seeing my module get a good\nreview in a book written by someone else really makes my day. My thanks to Nate Padwardhan and\nClay Irving (Programming with Perl Modules -- part of the O'Reilly Perl Resource Kit); and Tom\nChristiansen and Nathan Torkington (The Perl Cookbook). Also, thanks to any other authors who've\nwritten about Date::Manip who's books I haven't seen.\n\nI'd also like to thank the people who are maintaining the zoneinfo database (and who replied\nquickly to several inquiries).\n\nI have borrowed from other modules. I originally borrowed the code for determining if a year was\na leap year from code written by David Muir Sharnoff. I borrowed many of the original date\nprintf formats from code written by Terry McGonigal as well as the Solaris date command. More\nrecently, I borrowed the code to do time zone registry lookups on Windows from the\nDateTime-TimeZone module, though I rewrote it to work better with Date::Manip.\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::Misc - Miscellaneous information about Date::Manip  SHOULD I USE DATE::MANIP If you look in CPAN, you'll find that there are a number of Date and Time packages. Is Date::Manip the one you should be using? That isn't a trivial question to answer. It depends to a large extent on what you are trying to do.  Date::Manip is certainly one of the most powerful of the Date modules (the other main contender being the DateTime suite of modules). I'm trying to build a library which can do EVERY conceivable date/time manipulation that you'll run into in everyday life dealing with the Gregorian calendar. To the best of my knowledge, it will do everything that any other date module will do which work with the Gregorian calendar, and there are a number of features that Date::Manip has that other modules do not have.  There is a tradeoff in being able to do \"everything\"... and that tradeoff is primarily in terms of performance. Date::Manip is written entirely in Perl and is the largest of the date modules. Other modules tend to be faster than Date::Manip, and modules written in C are significantly faster than their Perl counterparts (at least if they're done right). Although I am working on making Date::Manip faster, it will never be as fast as other modules. And before anyone asks, Date::Manip will never be translated to C (at least by me). I write C because I have to. I write Perl because I like to. Date::Manip is something I do because it interests me, not something I'm paid for.  If you are going to be using the module in cases where performance is an important factor, and you're doing a fairly small set of simple date operations over and over again, you should carefully examine the other date modules to see if they will meet your needs.  Date::Manip does NOT provide functionality for working with alternate calendars such as the Chinese or Hebrew calendars, so if you need that functionality, you definitely need to look elsewhere (the DateTime suite probably).  On the other hand, if you want one solution for all your date needs, don't need peak speed, or are trying to do more exotic date operations, Date::Manip is for you. Operations on things like business dates, foreign language dates, holidays and other recurring events, complete timezone handling, etc. are available more-or-less exclusively in Date::Manip. At the very least, if you want to be able to do these operations, it will require using several other modules, each with it's own interface. Also, when you work with Date::Manip, you work with one author and one module. The DateTime suite currently consists of almost 100 modules and 75 authors.  In addition, I am making significant performance improvements in Date::Manip. Although it will never be as fast as some of the other perl modules, I believe that it is already competitive enough for most purposes, and I continue to look for places where I can improve performance, so performance should improve over time.",
    "flags": [],
    "examples": [],
    "see_also": []
}