Date::Manip::Problems man page on Mandriva

Man page or keyword search:  
man Server   17060 pages
apropos Keyword Search (all sections)
Output format
Mandriva logo
[printable version]

Date::Manip::Problems(User Contributed Perl DocumentatDate::Manip::Problems(3)

NAME
       Date::Manip::Problems - problems and bugs

KNOWN PROBLEMS
       The following are not bugs in Date::Manip, but they may give some
       people problems.

       Unable to determine Time Zone
	   Please refer to the Date::Manip::TZ documentation for a discussion
	   of this problem.

       Calculations appear to be off by an hour
	   Within days of releasing 6.00, I got the following report:

	      print DateCalc(ParseDate("2009/10/31"), "+1 day"), "\n";
	      print DateCalc(ParseDate("2009/11/01"), "+1 day"), "\n";
	      print DateCalc(ParseDate("2009/11/02"), "+1 day"), "\n";

	   produced:

	      2009110100:00:00
	      2009110123:00:00
	      2009110300:00:00

	   In other words, the second calculation appears to be off by one
	   hour.  In actuality, the result is correct. In the user's timezone,
	   daylight saving time ended on Nov 1, and the results are correct.
	   In America/New_York time (which has the same result), the
	   calculation means that:

	      2009-11-01 00:00:00 EDT + 24 hours =
	      2009-11-01 23:00:00 EST

	   which is correct.

       Missing date formats
	   Due to the large number of date formats that Date::Manip CAN
	   process, people often assume that other formats that they want to
	   use should work as well, and when they don't, it comes as a
	   surprise.

	   With the much improved parsing of 6.00, many formats can be added
	   easily, though unless they are of general use, I'll probably
	   suggest that you use parse_format instead.

	   There is a class of formats that I will not add however.

	   I have frequently been asked to add formats such as "the 15th of
	   last month", or "Monday of next week". I will NOT add these date
	   formats to Date::Manip. Since I have received the request several
	   times, I decided to include my reasoning here.

	   Date::Manip can parse pretty much any static date format that I
	   could think of or find reference to. Dates such as "today", "Jan
	   12", or "2001-01-01" are all understood.

	   These are fairly limited however. Many very common date formats are
	   best thought of as a date plus a modification. For example,
	   "yesterday" is actually determined internally as "today" plus a
	   modification of "- 1 day".  "2nd Sunday in June" is determined as
	   "June 1" modified to the 2nd Sunday.

	   As these types of formats were added over time, I quickly realized
	   that the number of possible date plus modification formats was
	   huge. The number of combinations has caused the parsing in
	   Date::Manip to be quite complex, and adding new formats
	   occasionally causes unexpected conflicts with other formats.

	   The first time I received a request similar to "the 15th of last
	   month", I intended to add it, but as I analyzed it to see what
	   changes needed to be made to support it, I realized that this
	   needed to be expressed as a date plus TWO modifications. In other
	   words, today modified to last month modified to the 15th day of the
	   month.

	   As bad as date plus modification formats are, a date plus TWO
	   modifications would be exponentially worse. On realizing that, I
	   made a firm decision that Date::Manip will NOT support this type of
	   format now, or at any time in the future. Although I apologize for
	   the inconvenience, I do not intend to change my position on this.

       Date::Manip is slow
	   NOTE: The following section applies primarily to 5.xx. I'm doing a
	   lot of work to optimize Date::Manip and I will rewrite this section
	   to take this into account, and to provide performance suggestions.

	   Date::Manip is probably one of the slower Date/Time modules due to
	   the fact that it is huge and written entirely in perl.

	   Some things that will definitely help:

	   ISO-8601 dates are parsed first and fastest.	 Use them whenever
	   possible.

	   Avoid parsing dates that are referenced against the current time
	   (in 2 days, today at noon, etc.).  These take a lot longer to
	   parse.

	   Business date calculations are extremely slow.  You should consider
	   alternatives if possible (i.e. doing the calculation in exact mode
	   and then multiplying by 5/7).  Who needs a business date more
	   accurate than "6 to 8 weeks" anyway, right :-)

       RCS Control
	   If you try to put Date::Manip under RCS control, you are going to
	   have problems.  Apparently, RCS replaces strings of the form
	   "$Date...$" with the current date.  This form occurs all over in
	   Date::Manip.	 To prevent the RCS keyword expansion, checkout files
	   using:

	      co -ko

	   Since very few people will ever have a desire to do this (and I
	   don't use RCS), I have not worried about it, and I do not intend to
	   try to workaround this problem.

       Using functions/methods which are not supported
	   There have been a handful of incidents of people using a function
	   from Date::Manip which were not documented in the manual.

	   Date::Manip consists of a large number of user functions which are
	   documented in the manual. These are designed to be used by other
	   programmers, and I will not make any backwards incompatible changes
	   in them unless there is a very compelling reason to do so, and in
	   that case, the change will be clearly documented in the
	   Date::Manip::Changes6 documentation for this module.

	   Date::Manip also consists of a large number of functions which are
	   NOT documented. These are for internal use only.  Please do not use
	   them!  I can (and do) change their use, and even their name,
	   without notice, and without apology!	 Some of these internal
	   functions even have test scripts, but that is not a guarantee that
	   they will not change, nor is any support implied. I simply like to
	   run regression tests on as much of Date::Manip as possible.

	   As of the most recent versions of Date::Manip, all internal
	   functions have names that begin with an underscore (_). If you
	   choose to use them directly, it is quite possible that new versions
	   of Date::Manip will cause your programs to break due to a change in
	   how those functions work.

	   Any changes to internal functions will not be documented, and will
	   not be regarded by me as a backwards incompatibility. Nor will I
	   (as was requested in one instance) revert to a previous version of
	   the internal function.

	   If you feel that an internal function is of more general use, feel
	   free to contact me with an argument of why it should be "promoted".
	   I welcome suggestions and will definitely consider any such
	   request.

BUGS AND QUESTIONS
       If you find a bug in Date::Manip, please send it directly to me (see
       the AUTHOR section below).  Alternately, you can submit it on CPAN.
       This can be done at the following URL:

	  http://rt.cpan.org/Public/Dist/Display.html?Name=Date-Manip

       Please do not use other means to report bugs (such as Usenet
       newsgroups, or forums for a specific OS or Linux distribution) as it is
       impossible for me to keep up with all of them.

       When filing a bug report, please include the following information:

       ·   The version of Date::Manip you are using.  You can get this by
	   using the script:

	      use Date::Manip;
	      print DateManipVersion(1),"\n";

	   or

	      use Date::Manip::Date;
	      $obj = new Date::Manip::Date;
	      print $obj->version(1),"\n";

       ·   The output from "perl -V"

       If you have a problem using Date::Manip that perhaps isn't a bug (can't
       figure out the syntax, etc.), you're in the right place.	 Start by
       reading the main Date::Manip documentation, and the other documents
       that apply to whatever you are trying to do.  If this still doesn't
       answer your question, mail me directly.

       I would ask that you be reasonably familiar with the documentation
       BEFORE you choose to do this. Date::Manip is a hobby, and I simply do
       not have time to respond to hundreds of questions which are already
       answered in this manual.

       If you find any problems with the documentation (errors, typos, or
       items that are not clear), please send them to me. I welcome any
       suggestions that will allow me to improve the documentation.

KNOWN BUGS
       None known.

SEE ALSO
       Date::Manip	  - main module documentation

LICENSE
       This script is free software; you can redistribute it and/or modify it
       under the same terms as Perl itself.

AUTHOR
       Sullivan Beck (sbeck@cpan.org)

perl v5.10.1			  2010-01-12	      Date::Manip::Problems(3)
[top]

List of man pages available for Mandriva

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net