{ "content": [ { "type": "text", "text": "# Date::Manip::Config (perldoc)\n\n## NAME\n\nDate::Manip::Config - Date::Manip configuration\n\n## SYNOPSIS\n\nThis documents the configuration information which is stored in each Date::Manip::Base object,\nhow to modify this information, and how the information is used in the other Date::Manip\nmodules.\n\n## DESCRIPTION\n\nDate::Manip is a very configurable bundle of modules. Many of it's behaviors can be modified to\nchange how date operations are done. To do this, a list of configuration variables may be set\nwhich define many Date::Manip behaviors.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **CONFIG FILES**\n- **BASIC CONFIGURATION VARIABLES**\n- **DATE PARSING CONFIGURATION VARIABLES**\n- **BUSINESS CONFIGURATION VARIABLES**\n- **RECURRENCE CONFIGURATION VARIABLES**\n- **TIME ZONE RELATED CONFIGURATION VARIABLES**\n- **DEPRECATED CONFIGURATION VARIABLES**\n- **KNOWN BUGS**\n- **BUGS AND QUESTIONS**\n- **SEE ALSO**\n- **LICENSE**\n- **AUTHOR**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "Date::Manip::Config", "section": "", "mode": "perldoc", "summary": "Date::Manip::Config - Date::Manip configuration", "synopsis": "This documents the configuration information which is stored in each Date::Manip::Base object,\nhow to modify this information, and how the information is used in the other Date::Manip\nmodules.", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 4, "subsections": [] }, { "name": "DESCRIPTION", "lines": 37, "subsections": [] }, { "name": "CONFIG FILES", "lines": 56, "subsections": [] }, { "name": "BASIC CONFIGURATION VARIABLES", "lines": 130, "subsections": [] }, { "name": "DATE PARSING CONFIGURATION VARIABLES", "lines": 64, "subsections": [] }, { "name": "BUSINESS CONFIGURATION VARIABLES", "lines": 59, "subsections": [] }, { "name": "RECURRENCE CONFIGURATION VARIABLES", "lines": 21, "subsections": [] }, { "name": "TIME ZONE RELATED CONFIGURATION VARIABLES", "lines": 160, "subsections": [] }, { "name": "DEPRECATED CONFIGURATION VARIABLES", "lines": 7, "subsections": [] }, { "name": "KNOWN BUGS", "lines": 2, "subsections": [] }, { "name": "BUGS AND QUESTIONS", "lines": 3, "subsections": [] }, { "name": "SEE ALSO", "lines": 2, "subsections": [] }, { "name": "LICENSE", "lines": 3, "subsections": [] }, { "name": "AUTHOR", "lines": 2, "subsections": [] } ], "sections": { "NAME": { "content": "Date::Manip::Config - Date::Manip configuration\n", "subsections": [] }, "SYNOPSIS": { "content": "This documents the configuration information which is stored in each Date::Manip::Base object,\nhow to modify this information, and how the information is used in the other Date::Manip\nmodules.\n", "subsections": [] }, "DESCRIPTION": { "content": "Date::Manip is a very configurable bundle of modules. Many of it's behaviors can be modified to\nchange how date operations are done. To do this, a list of configuration variables may be set\nwhich define many Date::Manip behaviors.\n\nThere are three ways to set config variables. The first two are to pass them in when creating an\nobject, or to pass them to the config method after the object is created. All of the main\nDate::Manip modules (Date::Manip::Base, Date::Manip::TZ, Date::Manip::Date, Date::Manip::Delta,\nand Date::Manip::Recur) have the config method.\n\nAs an example, you can create and configure a Date::Manip::Date object using the commands:\n\n$date = new Date::Manip::Date;\n$date->config($var1,$val1,$var2,$val2,...);\n\nThis can be shortened to:\n\n$date = new Date::Manip::Date [$var1,$val1,...];\n\nThe values of the config variables are stored in the Date::Manip::Base object. So, if you have a\nDate::Manip::Date object, it has a Date::Manip::Base object associated with it, and the\nconfiguration information is stored there. The same Date::Manip::Base object may be used by any\nnumber of higher objects, and all will share the same configuration. If multiple\nDate::Manip::Date objects share the same Date::Manip::Base object, setting a configuration\nvariable on any of them affects all of the Date::Manip::Date objects. If you need to work with\ndifferent configurations simultaneously, it is necessary to work with multiple Date::Manip::Base\nobjects. This is covered in the Date::Manip::Objects document.\n\nAn alternate method exists if you are using one of the functional interfaces. To set a variable\nusing the functional interface, use the call:\n\nDateInit(\"$var1=$val1\");\n\nThe third way to set config variables is to store them in a config file. The config file is read\nin by passing the appropriate values to the config method as described below. A config file is a\ngood way to easily change a large number of settings. They are also necessary for other purposes\n(such as events and holidays which are covered in the Date::Manip::Holidays document).\n", "subsections": [] }, "CONFIG FILES": { "content": "One of the variables that can be passed to the config method is \"ConfigFile\". The value of this\nvariable is the path to a config file.\n\nWhen any Date::Manip::* object is configured, any number of config files may be read (and the\nconfig files can specify additional files to read).\n\nThe starting section of a config file contains general configuration variables. A list of all\nconfig variables is given below.\n\nFollowing this, any number of special sections may be included in the config file. The special\nsections are used to specify other types of information, such as a list of holidays or special\nevents. These special sections are described elsewhere in the documentation.\n\nThe syntax of the config file is very simple. Every line is of the form:\n\nVAR = VAL\n\nor\n\n*SECTION\n\nBlank lines and lines beginning with a pound sign (#) are ignored. All whitespace is optional.\nVariables names in the main section and section names are case insensitive (though values in the\nmain section are typically case sensitive). Strings in other sections (both variables and\nvalues) are case sensitive.\n\nThe following is a sample config file:\n\nDateFormat = US\nLanguage = English\n\n*Holidays\n\nDec 25 = Christmas\nJan 1 = New Year's\n\nAll config variables that may appear in the main part of a config file are described in the next\nsection. Other sections are described elsewhere. The *Holidays and *Events sections are both\ndescribed in the Date::Manip::Holidays documentation.\n\nA sample config file is included with the Date::Manip distribution. Modify it as appropriate and\ncopy it to some appropriate directory and use the ConfigFile variable to access it. For example,\nif a config file is stored in /home/foo/Manip.cnf, you can load it by:\n\n$date->config(\"ConfigFile\",\"/home/foo/Manip.cnf\");\n\nor (if using a functional interface):\n\nDateInit(\"ConfigFile=/home/foo/Manip.cnf\");\n\nNOTE: if you use business mode calculations, you must have a config file since this is the only\nplace where you can define holidays.\n\nIn the top section, only variables described below may be used. In other sections, checking (if\nany) is done in the module that uses the data from that section.\n", "subsections": [] }, "BASIC CONFIGURATION VARIABLES": { "content": "This section describes the basic Date::Manip configuration variables which can be used in a\nconfig file, or which may be passed in using the appropriate functions for each module.\n\nVariable names are case insensitive, both as arguments to the config function and in the config\nfile. The values are case sensitive except where specified otherwise.\n\nDefaults\nThe value for this config variable is ignored. Whenever the Defaults config variable is\nencountered, the defaults for all config variables are restored, overriding ALL changes that\nhave been made.\n\nIn other words, in the following call:\n\n$date->config(\"Language\",\"Russian\",\n\"Defaults\",\"1\");\n\nthe first option will end up being ignored since the Defaults config variable will set the\nlanguage back to it's default value which is English.\n\nWhen using a functional interface, use:\n\nDateInit(\"Defaults=1\");\n\nConfigFile\nThe ConfigFile variable defines a config file which will be parsed for configuration\ninformation. It may be included any number of times, each one including the path to a single\nconfig file. The value of this variable is a full path to a file.\n\nAn example call to the config function might be:\n\n$date->config(\"ConfigFile\",\"/tmp/file1\",\n'Language',$val);\n\nConfig files are parsed immediately when encountered. So in this example, the file\n/tmp/file1 will be parsed before the next variable ('Language'). In addition, if a config\nfile contains a ConfigFile variable, that file will immediately be parsed before continuing\nwith the original file.\n\nThe path to the file may be specified in any way valid for the operating system. If a file\nis not found, a warning will be issued, but execution will continue.\n\nMultiple config files are safe, and a section may safely be split across multiple files.\n\nWhen using a functional interface, use:\n\nDateInit(\"ConfigFile=/tmp/file1\");\n\nLanguage\nDate::Manip can be used to parse dates in many different languages. A list of the languages\nis given in the Date::Manip::Lang document.\n\nTo parse dates in a different language, just use the Language config variable with the name\nof the language as the value. Language names are case insensitive.\n\nAdditional languages may be added with the help of someone fluent in English and the other\nlanguage. If you are interested in providing a translation for a new language, please refer\nto the Date::Manip::Lang document for instructions.\n\nEncoding\nDate::Manip has some support for handling date strings encoded in alternate character\nencodings.\n\nBy default, input strings may be tested using multiple encodings that are commonly used for\nthe specific languages, as well as using standard perl escape sequences, and output is done\nin UTF-8.\n\nThe input, output, or both can be overridden using the Encoding variable.\n\nSetting Encoding to the name of a single encoding (a name supported by the Encoding perl\nmodule), will force all input and output to be done in that encoding.\n\nSo, setting:\n\nEncoding = iso-8859-1\n\nmeans that all input and output will be in that encoding. The encoding 'perl' has the\nspecial meaning of storing the string in perl escape sequences.\n\nEncoding can also be set to the name of two encoding (separated by a comma).\n\nEncoding = iso-8859-1,utf-16\n\nwhich means that all input is in iso-8859-1 encoding, but all output will be utf-16.\n\nEncoding may also be set as follows:\n\nEncoding = iso-8859-1,\n\nmeaning that input is in iso-8859-1 and output is in the default (i.e. UTF-8) encoding.\n\nEncoding = ,utf-16\n\nmeans to check the input in all of the encodings, but all output will be in utf-16 encoding.\n\nNote that any time you change languages, it will reset the encodings, so you should set this\nconfig variable AFTER setting the language.\n\nFirstDay\nIt is sometimes necessary to know what day of week is regarded as first. By default, this is\nset to Monday as that conforms to ISO 8601, but many countries and people will prefer Sunday\n(and in a few cases, a different day may be desired). Set the FirstDay variable to be the\nfirst day of the week (1=Monday, 7=Sunday).\n\nJan1Week1\nISO 8601 states that the first week of the year is the one which contains Jan 4 (i.e. it is\nthe first week in which most of the days in that week fall in that year). This means that\nthe first 3 days of the year may be treated as belonging to the last week of the previous\nyear. If this is set to non-nil, the ISO 8601 standard will be ignored and the first week of\nthe year contains Jan 1.\n\nPrintable\nSome commands may produce a printable version of a date. By default, the printable version\nof the date is of the format:\n\nYYYYMMDDHH:MN:SS\n\nTwo other simple versions have been created. If the Printable variable is set to 1, the\nformat is:\n\nYYYYMMDDHHMNSS\n\nIf Printable is set to 2, the format is:\n\nYYYY-MM-DD-HH:MN:SS\n\nThis config variable is present in order to maintain backward compatibility, and may\nactually be deprecated at some point. As such, additional formats will not be added.\nInstead, use the printf method in the Date::Manip::Date module to extract information with\ncomplete flexibility.\n", "subsections": [] }, "DATE PARSING CONFIGURATION VARIABLES": { "content": "DateFormat\nDifferent countries look at the date 12/10 as Dec 10 or Oct 12. In the United States, the\nfirst is most common, but this certainly doesn't hold true for other countries. Setting\nDateFormat to \"US\" (case insensitive) forces the first behavior (Dec 10). Setting DateFormat\nto anything else forces the second behavior (Oct 12). The \"US\" setting is the default (sorry\nabout that... I live in the US).\n\nYYtoYYYY\nWhen parsing a date containing a 2-digit year, the year must be converted to 4 digits. This\nconfig variable determines how this is done.\n\nBy default, a 2 digit year is treated as falling in the 100 year period of CURR-89 to\nCURR+10. So in the year 2005, a two digit year will be somewhere in the range 1916 to 2015.\n\nYYtoYYYY may be set to any integer N to force a 2 digit year into the period CURR-N to\nCURR+(99-N). A value of 0 forces the year to be the current year or later. A value of 99\nforces the year to be the current year or earlier. Although the most common choice of values\nwill be somewhere between 0 and 99, there is no restriction on N that forces it to be so. It\ncan actually be any positive or negative number you want to force it into any 100 year\nperiod desired.\n\nYYtoYYYY can also be set to \"C\" to force it into the current century, or to \"C##\" to force\nit into a specific century. So, in 1998, \"C\" forces 2 digit years to be 1900-1999. \"C18\"\nwould always force a 2 digit year to be in the range 1800-1899. Note: I'm aware that the\nactual definitions of century are 1901-2000, NOT 1900-1999, so for purists, treat this as\nthe way to supply the first two digits rather than as supplying a century.\n\nIt can also be set to the form \"C####\" to force it into a specific 100 year period. C1950\nrefers to 1950-2049.\n\nDefaultTime\nWhen a date is parsed from one of the formats listed in the \"Common date formats\" or \"Less\ncommon formats\" sections of the Date::Manip::Date document, and no time is explicitly\nincluded, the default time can be determined by the value of this variable. The two possible\nvalues are:\n\nmidnight the default time is 00:00:00\ncurr the default time is the current time\n\n\"midnight\" is the default value.\n\nNOTE: this only applies to dates parsed with the parse method. Dates parsed using the\nparsedate method always default to 00:00:00.\n\nPeriodTimeSep\nBy default, the time separator (i.e. the character that separates hours from minutes and\nminutes from seconds) is specified in the language translations and in most cases it does\nnot include a period. In English, the only defined time separator is a colon (:), so the\ntime can be written as 12:15:30 .\n\nIf you want to use a period (.) as a time separator as well, set this to 1. Then you can\nwrite the time as 12.15.30 .\n\nBy default, a period is used as a date separator, so 12.15.30 would be interpreted as Dec 15\n1930 (or 2030), so if you use the period as a date separator, it should not be used as a\ntime separator too.\n\nFormatMMMYYYY\nBy default, when parsing a string like 'Jun 1925', it will be interpreted as 'Jun 19, 2025'\n(i.e. MMM DDYY). Also, the string '1925 Jun' is not allowed.\n\nThis variable can be set to either 'first' or 'last', and in that case, both 'Jun 1925' and\n'1925 Jun' will be allowed, and will refer to either the first or last day of June in 1925.\n", "subsections": [] }, "BUSINESS CONFIGURATION VARIABLES": { "content": "These are configuration variables used to define work days and holidays used in business mode\ncalculations. Refer to the Date::Manip::Calc documentation for details on these calculations.\n\nWorkWeekBeg\nWorkWeekEnd\nThe first and last days of the work week. These default to Monday and Friday. Days are\nnumbered from 1 (Monday) to 7 (Sunday). WorkWeekBeg must come before WorkWeekEnd numerically\nso there is no way to handle a work week of Sunday to Thursday using these variables.\n\nThere is also no way to handle an odd work schedule such as 10 days on, 4 days off.\n\nHowever, both of these situations can be handled using a fairly simple workaround.\n\nTo handle a work week of Sunday to Thursday, just set WorkWeekBeg=1 and WorkWeekEnd=7 and\ndefined a holiday that occurs every Friday and Saturday.\n\nTo handle a 10 days on, 4 days off schedule, do something similar but defined a holiday that\noccurs on all of the 4 days off.\n\nBoth of these can be done using recurrences. Refer to the Date::Manip::Recur documentation\nfor details.\n\nWorkDay24Hr\nWorkDayBeg\nWorkDayEnd\nIf WorkDay24Hr is non-zero, a work day is treated as usually being 24 hours long (daylight\nsaving time changes ARE taken into account). The WorkDayBeg and WorkDayEnd variables are\nignored in this case.\n\nBy default, WorkDay24Hr is zero, and the work day is defined by the WorkDayBeg and\nWorkDayEnd variables. These are the times when the work day starts and ends respectively.\nWorkDayBeg must come before WorkDayEnd (i.e. there is no way to handle the night shift where\nthe work day starts one day and ends another).\n\nThe time in both should be a valid time format (H, H:M, or H:M:S).\n\nNote that setting WorkDay24Hr to a non-zero value automatically sets WorkDayBeg and\nWorkDayEnd to \"00:00:00\" and \"24:00:00\" respectively, so to switch back to a non-24 hour\nday, you will need to reset both of those config variables.\n\nSimilarly, setting either the WorkDayBeg or WorkDayEnd variables automatically turns off\nWorkDay24Hr.\n\nTomorrowFirst\nPeriodically, if a day is not a business day, we need to find the nearest business day to\nit. By default, we'll look to \"tomorrow\" first, but if this variable is set to 0, we'll look\nto \"yesterday\" first. This is only used in the \"Date::Manip::Date::nearestbusinessday\"\nmethod (and the \"DateNearestWorkDay\" function) and is easily overridden (see documentation\nfor the nearestbusinessday method).\n\nEraseHolidays\nEraseEvents\nIf these variables are used (a value must be passed in, but is ignored), the current list of\ndefined holidays or events is erased. A new set will be set the next time a config file is\nread in.\n\nAlthough these variables are supported, the best way to have multiple holiday or events\nlists will be to create multiple Date::Manip::Base objects based on separate config files.\n", "subsections": [] }, "RECURRENCE CONFIGURATION VARIABLES": { "content": "The following config variables help in the handling of recurrences.\n\nRecurRange\nWhen a recurrence is created, it begins with a default range (start and end date). The range\nselected depends on the value of this variable, and can be set to any of the following:\n\nnone no default range supplied\nyear the current year\nmonth the current month\nweek the current week\nday the current day\nall Jan 2, 0001 to Dec 30, 9999\n\nThe default value is \"none\".\n\nMaxRecurAttempts\nOccasionally, a recurrence is invalid (though it cannot be easily determined in advance).\n\nWhen searching for dates that match the recurrence, this is the maximum number of attempts\nthat will be done. If none are found, the recurrence will be assumed to be invalid.\n", "subsections": [] }, "TIME ZONE RELATED CONFIGURATION VARIABLES": { "content": "The following configuration variables may alter the current time zone. As such, they are only\navailable once the Date::Manip::TZ module is available. An easy way to handle this is to only\npass them to the config method of a Date::Manip::TZ object or one of the high level objects\n(Date::Manip::Date, Date::Manip::Delta, or Date::Manip::Recur).\n\nMany of Date::Manip's operations rely on knowing what time it is now. This consists of three\nthings: knowing what date and time it is, knowing what time zone it is, and knowing whether it\nis daylight saving or not. All of this is necessary in order to correctly handle every possible\ndate.\n\nThe daylight saving time information is only used for a couple hours each year during daylight\nsaving time changes (at all other times, the date, time, and time zone are sufficient\ninformation), so it is optional, and defaults to standard time if omitted.\n\nThe default behavior of Date::Manip is to use the system localtime function to determine the\ndate, time, and daylight saving time information, and to use various methods (see \"DETERMINING\nTHE SYSTEM TIME ZONE\" in Date::Manip::TZ) to determine what time zone the computer is in.\n\nTZ This variable is deprecated, but will be supported for several releases. The SetDate or\nForceDate variables (described next) should be used instead.\n\nThe following are equivalent:\n\n$date->config(\"tz\",\"Europe/Rome\");\n$date->config(\"setdate\",\"now,Europe/Rome\");\n\nor in the functional interface:\n\nDateInit(\"tz=Europe/Rome\");\nDateInit(\"setdate=now,Europe/Rome\");\n\nSetDate\nThe SetDate config variable is used to set the current date, time, or time zone, but then\nallow it to change over time using the rules of that time zone.\n\nThere are several cases where this may be useful.\n\nOften, you may want to use the system time to get the date and time, but you want to work in\nanother time zone. For this, use the call:\n\n$date->config(\"setdate\",\"now,ZONE\");\n\nor in the function interface:\n\nDateInit(\"setdate=now,ZONE\");\n\nIf it is currently\n\nJun 6, 2009 12:00:00 in the America/NewYork time zone\n\nand you call:\n\n$date->config(\"setdate\",\"now,Europe/Rome\");\n\nthe Date::Manip will treat that exact instant as\n\nJun 6, 2009 12:00:00 in the Europe/Rome time zone\n\nAt that precise moment, looking at the system time and parsing the date \"now\" in Date::Manip\nwill give the same date and time.\n\nThe time will continue to advance, but it will use time change rules from the Europe/Rome\ntime zone. What that means is that if a daylight saving time occurs on the computer, but NOT\nin the Europe/Rome time zone (or vice versa), the system date and time will no longer match\nthe results of parsing the date \"now\" in Date::Manip.\n\nIn general (unless the program runs for an extended period of time), the system date and\ntime WILL match the value of \"now\", so this is a good way to simulate placing the computer\nin another time zone.\n\nIf the current date/time is ambiguous (i.e. it exists in both standard and daylight saving\ntime in the alternate zone), you can use the call:\n\n$date->config(\"setdate\",\"now,DSTFLAG,ZONE\");\n\nto force it to be in one or the other. DSTFLAG can be \"std\", \"dst\", \"stdonly\", or \"dstonly\".\n\"std\" and \"dst\" mean that the date can be in either standard or saving time, but will try\nstandard first (for \"dst\") or saving time first (if \"dst\"), and will only try the other if\nthe date is not valid. If \"stdonly\" or \"dstonly\" is used, the date will be forced to be\nstandard or saving time respectively (an error will be triggered if there is no valid date\nin that time).\n\nIf the current date/time doesn't exist in the alternate zone, an error will occur.\n\nThe other common operation is that you might want to see results as they would appear on a\ncomputer running in a different time zone.\n\nThis can be done using the call:\n\n$date->config(\"setdate\",\"zone,ZONE\");\n$date->config(\"setdate\",\"zone,DSTFLAG,ZONE\");\n\nIf it is currently\n\nJun 6, 2009 12:00:00 in the America/NewYork time zone\n\nand you call:\n\n$date->config(\"setdate\",\"zone,America/Chicago\");\n\nthen parsing \"now\" at precisely that moment will return \"Jun 6, 2009 11:00:00\". This is\nequivalent to working in the current zone, but then converting everything to the alternate\nzone.\n\nNote that DSTFLAG is only used if ZONE is entered as an offset.\n\nThe final case where the SetDate config variable is used is to alter the date and time to\nsome other value (completely independent of the current date and time) and allow it to\nadvance normally from that point.\n\n$date->config(\"setdate\",\"DATE\");\n$date->config(\"setdate\",\"DATE,ZONE\");\n$date->config(\"setdate\",\"DATE,DSTFLAG,ZONE\");\n\nset both the date/time and zone.\n\nIf DATE is not valid in the time zone (either the local time zone or the specified one), and\nerror occurs.\n\nThe call:\n\n$date->config(\"setdate\",\"now\");\n\nresets everything to use the current date/time and zone and lets it advance normally.\n\nForceDate\nThe ForceDate config variable is similar to the SetDate variable, except that once \"now\" is\nset, it is not allowed to change. Parsing the date \"now\" will not change, regardless of how\nlong the program runs (unless either the SetDate or ForceDate variables are set to some\nother value).\n\n$date->config(\"forcedate\",\"now,ZONE\");\n$date->config(\"forcedate\",\"now,DSTFLAG,ZONE\");\n$date->config(\"forcedate\",\"zone,ZONE\");\n$date->config(\"forcedate\",\"zone,DSTFLAG,ZONE\");\n$date->config(\"forcedate\",\"DATE\");\n$date->config(\"forcedate\",\"DATE,ZONE\");\n$date->config(\"forcedate\",\"DATE,DSTFLAG,ZONE\");\n$date->config(\"forcedate\",\"now\");\n\nall set \"now\" in the same way as the SetDate variable. Spaces after commas are ignored.\n\nZONE can be any time zone name, alias, abbreviation, or offset, and the best time zone will be\ndetermined from all given information.\n\nIt should be noted that setting the SetDate or ForceDate variable twice will always refer to the\nsystem date/time as a starting point. For example, if a program is running, and calls the\nmethod:\n\n$date->config(\"forcedate\",\"now\");\n\nat Jun 6, 2009 at 12:00, that time will be treated as now from that point on. If the same call\nis done an hour later, \"now\" will then be Jun 6, 2009 at 13:00 from that moment on.\n\nSince the current date is used in the date parsing routines, no parsing can be done on the DATE\nvalue in any of the calls. Instead, DATE must be a date in one of the two formats:\n\nYYYY-MM-DD-HH:MN:SS\nYYYYMMDDHH:MN:SS\n", "subsections": [] }, "DEPRECATED CONFIGURATION VARIABLES": { "content": "The following config variables are currently supported, but are deprecated. They will be removed\nin a future Date::Manip release:\n\nTZ This is discussed above. Use SetDate or ForceDate instead.\n\nScheduled for removal 2016-03-01\n", "subsections": [] }, "KNOWN BUGS": { "content": "None known.\n", "subsections": [] }, "BUGS AND QUESTIONS": { "content": "Please refer to the Date::Manip::Problems documentation for information on submitting bug\nreports or questions to the author.\n", "subsections": [] }, "SEE ALSO": { "content": "Date::Manip - main module documentation\n", "subsections": [] }, "LICENSE": { "content": "This script is free software; you can redistribute it and/or modify it under the same terms as\nPerl itself.\n", "subsections": [] }, "AUTHOR": { "content": "Sullivan Beck (sbeck@cpan.org)\n", "subsections": [] } } } }