Date-Manip
view release on metacpan or search on metacpan
Deltas will also no longer support the 'exact' and 'approximate'
strings (which have not been supported for some time). These will be
removed in 7.00 as well.
- Deprecation of TZ postponed
The deprecation of the TZ variable has been postponed to version
7.00.
- Some speed improvements
I converted some of the functions to use faster algorithms.
Previously, the steps were worked out using logical time/calendar
based calculations. These were replaced with non-intuitive numerical
calculations that gave the same result faster.
- Changed behavior if timezone not determined
If the system timezone cannot be determined using any of the methods
supplied by Date::Manip, operations will be done in the GMT
timezone. Previously, Date::Manip would simply fail to load. Based
on a report by Kent Fredric (RT 123229).
- Fixed Makefile.PL
NAME
Date::Manip - Date manipulation routines
DESCRIPTION
Date::Manip is a series of modules designed to make any common date/time
operation easy to do. Operations such as comparing two times,
determining a date a given amount of time from another, or parsing
international times are all easily done. It deals with time as it is
used in the Gregorian calendar (the one currently in use) with full
support for time changes due to daylight saving time.
From the very beginning, the main focus of Date::Manip has been to be
able to do ANY desired date/time operation easily. Many other modules
exist which may do a subset of these operations quicker or more
efficiently, but no other module can do all of the operations available
in Date::Manip.
Date::Manip has functionality to work with several fundamental types of
data.
dates
The word date is used extensively here and is somewhat misleading.
In Date::Manip, a date consists of three pieces of information: a
calendar date (year, month, day), a time of day (hour, minute,
second), and time zone information. Calendar dates and times are
fully handled. Time zones are handled as well, but depending on how
you use Date::Manip, there may be some limitations as discussed
below.
delta
A delta is an amount of time (i.e. the amount of time between two
different dates). Think of it as the duration of an event or the
amount of time between two dates.
internal/data.misc.pl view on Meta::CPAN
%last_zone_offsets =
(
# "America/Resolute" => { "dst" => 0,
# "st" => 2, },
);
# The following zone(s) will not use a LAST RULE to calculate time zone
# changes past $keep_year. Instead, they will use all dates from a dump,
# and nothing beyond that.
#
# Asia/Jerusalem uses a non-standard way based on the Hebrew calendar.
%no_last = map { $_,1 } qw(Asia/Jerusalem Asia/Tehran);
1;
# Local Variables:
# mode: cperl
# indent-tabs-mode: nil
# cperl-indent-level: 3
# cperl-continued-statement-offset: 2
lib/Date/Manip.pod view on Meta::CPAN
=head1 NAME
Date::Manip - Date manipulation routines
=head1 DESCRIPTION
Date::Manip is a series of modules designed to make any common
date/time operation easy to do. Operations such as comparing two
times, determining a date a given amount of time from another, or
parsing international times are all easily done. It deals with time
as it is used in the Gregorian calendar (the one currently in use)
with full support for time changes due to daylight saving time.
From the very beginning, the main focus of Date::Manip has been to be
able to do ANY desired date/time operation easily. Many other modules
exist which may do a subset of these operations quicker or more
efficiently, but no other module can do all of the operations
available in Date::Manip.
Date::Manip has functionality to work with several fundamental types
of data.
=over 4
=item B<dates>
The word date is used extensively here and is somewhat misleading. In
Date::Manip, a date consists of three pieces of information: a
calendar date (year, month, day), a time of day (hour, minute,
second), and time zone information. Calendar dates and times are fully
handled. Time zones are handled as well, but depending on how you use
Date::Manip, there may be some limitations as discussed below.
=item B<delta>
A delta is an amount of time (i.e. the amount of time between two
different dates). Think of it as the duration of an event or the
amount of time between two dates.
lib/Date/Manip/Base.pod view on Meta::CPAN
$days = $dmb->days_in_year($y);
Returns the number of days in the year (365 or 366)
=item B<days_since_1BC>
$days = $dmb->days_since_1BC($date);
$days = $dmb->days_since_1BC($ymd);
Returns the number of days since Dec 31, 1BC. Since the calendar has
changed a number of times, the number returned is based on the current
calendar projected backwards in time, and in no way reflects a true
number of days since then. As such, the result is largely meaningless,
except when called twice as a means of determining the number of days
separating two dates.
The inverse operation is also available:
$ymd = $dmb->days_since_1BC($days);
Returns the date C<$days> since Dec 31, 1BC. So day 1 is Jan 1, 0001.
lib/Date/Manip/Changes5to6.pod view on Meta::CPAN
was +1:11:4:0:0:0:0 (or 1 year, 11 months, 4 weeks). As of
Date::Manip 6.00, the delta is +2:0:-0:3:0:0:0 (or 2 years minus 3
days). Although this leads to mixed-sign deltas, it is actually
how more people would think about the delta. It has the additional
advantage of being MUCH easier and faster to calculate.
=item B<Approximate relationships in deltas>
When printing parts of deltas in Date::Manip::5.xx, the approximate
relationship of 1 year = 365.25 days was used. This is the correct
value for the Julian calendar, but for the Gregorian calendar, a
better value is 365.2425, and this is used in version 6.00.
=item B<Old style formats>
The formats used in the printf command are slightly different than in the
old Delta_Format command.
The old formats are described in the Date::Manip::DM5 manual, and the
new ones are in the Date::Manip::Delta manual.
lib/Date/Manip/Changes6.pod view on Meta::CPAN
(which have not been supported for some time). These will be removed
in 7.00 as well.
=item Deprecation of TZ postponed
The deprecation of the TZ variable has been postponed to version 7.00.
=item Some speed improvements
I converted some of the functions to use faster algorithms. Previously, the
steps were worked out using logical time/calendar based calculations. These
were replaced with non-intuitive numerical calculations that gave the same
result faster.
=item Changed behavior if timezone not determined
If the system timezone cannot be determined using any of the methods
supplied by Date::Manip, operations will be done in the GMT timezone.
Previously, Date::Manip would simply fail to load. Based on a report by
Kent Fredric (RT 123229).
lib/Date/Manip/DM5.pod view on Meta::CPAN
events occur.
If no asterisks are included, then the entire recurrence is of this form.
For example,
0:0:0:1:12:0:0
refers to an event that occurs every 1 day, 12 hours.
Values that occur after an asterisk refer to a specific value for that type
of time element (i.e. exactly as it would appear on a calendar or a clock).
For example, if the recurrence ends with:
*12:0:0
then the recurring event occurs at 12:00:00 (noon).
For example:
0:0:2:1:0:0:0 every 2 weeks and 1 day
0:0:0:0:5:30:0 every 5 hours and 30 minutes
lib/Date/Manip/DM5.pod view on Meta::CPAN
Events can be based at any time of the day, and may be of any duration.
=item B<Events don't affect business mode calculations>
Unlike holidays, events are completely ignored when doing business
mode calculations.
=back
Whereas holidays were added with business mode math in mind, events
were added with calendar and scheduling applications in mind.
Every line in the events section is of the form:
EVENT = NAME
where NAME is the name of the event, and EVENT defines when it occurs
and its duration. An EVENT can be defined in the following ways:
Date
Date*
lib/Date/Manip/Date.pod view on Meta::CPAN
=head1 SYNOPSIS
use Date::Manip::Date;
$date = new Date::Manip::Date;
=head1 DESCRIPTION
This module works specifically with date objects.
Although the word date is used extensively here, it is actually
somewhat misleading. Date::Manip works with the full calendar date
(year, month, day, and week when appropriate), time of day (hour,
minute, second), and time zone. It doesn't work with fractional
seconds.
=head1 METHODS
=over 4
=item B<base>
lib/Date/Manip/Date.pod view on Meta::CPAN
=item B<parse>
$err = $date->parse($string [,@opts]);
This parses a string which should include a valid date and stores
it in the object. If the string does not include a valid date, an
error is returned. Use the err method to see the full error
message.
A full date may include a calendar date (year, month, day), a time of
day (hour, minute, second), and time zone information. All of this can
be entered in many different formats.
For information on valid date formats, refer to the section VALID
DATE FORMATS. For information on valid time zone information, refer
to the section VALID TIME ZONE FORMATS.
If no time zone information is included in the date, it is treated
as being in the local time zone.
lib/Date/Manip/Date.pod view on Meta::CPAN
specifies the year, month, and day and a complete time fully specifies
the hour, minute, and second.
It should be understood that in many instances, the information may be
implied rather than explicitly stated, but it is still treated as
complete.
For example, the date "January 3" is complete because it implies the
current year.
A truncated calendar date or time does not include information about
some of the fields. Date::Manip will never work with a partial date or
time, so defaults will be supplied.
For example, the date "2009-01" is missing a day field, so a default
will be used. In this case, the day will be the 1st, so this is
equivalent to "Jan 1st 2009". If only the year is given, it will
default to Jan 1.
If the time, or any of it's components is missing, they default to
00. So the time "12:30" and "12:30:00" are equivalent.
lib/Date/Manip/Date.pod view on Meta::CPAN
These formats explicitly set the date, but not the time. These formats
may be combined with a time string (as specified below) to set both
the date and time. If this is not done, the default time is determined
by the DefaultTime config variable.
=over 4
=item B<ISO 8601 dates>
The preferred date formats are those specified by ISO 8601. The
specification includes valid calendar date and valid time formats.
Date::Manip will handle all of these formats, but does not require
that the dates rigidly adhere to the specification since the ultimate
goal of Date::Manip is to handle dates as they are represented in
real life and some common variations exist which are similar to, but
not identical to, those from the specification.
A calendar date includes the following fields:
CC 2-digit representation of the century
YY 2-digit representation of the year in
a century
MM 2-digit representation of a month
DD 2-digit representation of a day of month
DoY 3-digit representation of a day of year
(001-366)
Www the character "W" followed by a 2-digit
week of the year (01-53)
lib/Date/Manip/Date.pod view on Meta::CPAN
dashes present) or abbreviate form (with no dashes). As of 6.00, this
is the behavior, so the formats: YYMMDD and YY-MM-DD are allowed, as
per the specification, but the format YY-MMDD is NOT allowed (though
it was previously).
The Www-D formats require a bit of explanation. According to the
specification, the date:
1996-w02-3
refers to the day with an ordinal number of 3 within the calendar week
in the 2nd week of 1996.
In the specification, the days of the week are numbered from 1 to 7
(Monday to Sunday), and the week always begins on Monday, so day 1
(Monday) is always the first day of the week, day 2 (Tuesday) is
always the second day of the week, etc.
In Date::Manip, the constraint that the week must start with Monday is
relaxed, allowing the week to begin with Sunday (a far more common
start of the week in calendars, at least in some parts of the world).
This presents a problem though in that the above date could be
interpreted as Wednesday (day 3) of the 2nd week of 1996, or as the
3rd day of the 2nd week of 1996 (which would normally be Wednesday,
but would be Tuesday if the week begins on Sunday).
As of Date::Manip 6.00, the above date will be interpreted as the 3rd
day of the 2nd week. This is a reversal from Date::Manip 5.xx, but I
believe is what the specification would require. For more information,
refer to the Date::Manip::Changes document.
lib/Date/Manip/Date.pod view on Meta::CPAN
based on English equivalents.
There are probably many different dates that are perfectly valid, and
in common usage, in other languages which do not have an equivalent in
the English language, and unfortunately, Date::Manip will probably not
parse these.
You are free to send these to me, and I'll see if there is a way to
add them in, but I do not guarantee anything. Without having a
full-blown language parser (or at least the portion of the language
that is devoted to calendar and time), most of these formats will
simply not be supportable.
=head1 VALID TIME FORMATS
There are several categories of time formats supported by Date::Manip.
These are strings which specify only the hour/minute/second fields.
=over 4
=item B<ISO 8601 times>
lib/Date/Manip/Delta.pod view on Meta::CPAN
ending time.
There are several concepts involved in understanding the properties
of a delta.
=over 4
=item B<standard and business delta>
There are two different modes for working with deltas: standard and
business. The mode used depends on how you treat the calendar.
Standard deltas use the full calendar without any modifications.
A business delta uses a calendar in the way a business might. In a
business calendar, anything outside of a business day is ignored.
Typically, this includes holidays and weekends. In addition, the part
of the day outside of business hours is also ignored, so a day may
only run from 08:00 to 17:00 and everything outside of this is
ignored.
The length of a work day is usually not 24 hours. It is defined by
the start and end of the work day and is set using the config
variables: B<WorkDayBeg> and B<WorkDayEnd> (B<WorkDay24Hr> may be used to
specify a 24-hour work day). The work week is defined using the
config variables: B<WorkWeekBeg> and B<WorkWeekEnd>.
lib/Date/Manip/Holidays.pod view on Meta::CPAN
Date::Manip::Holidays - describes holidays and events
=head1 SYNOPSIS
This describes the Holidays and Events sections of the config file,
and how they are used.
Holidays and events are specific days that are named. Holidays are
used in business mode calculations, events are not. Events may be used
for other calendaring operations.
=head1 HOLIDAYS
The holiday section of the config file is used to define holidays. Each
line is of the form:
STRING = HOLIDAY
HOLIDAY is the name of the holiday or it can be blank.
lib/Date/Manip/Holidays.pod view on Meta::CPAN
Events can be based at any time of the day, and may be of any duration.
=item B<Events don't affect business mode calculations>
Unlike holidays, events are completely ignored when doing business
mode calculations.
=back
Whereas holidays were added with business mode math in mind, events
were added with calendar and scheduling applications in mind.
Every line in the events section is of the form:
EVENT = NAME
where NAME is the name of the event, and EVENT defines when it occurs
and its duration. An EVENT can be defined in the following ways:
Date
YMD
lib/Date/Manip/Misc.pod view on Meta::CPAN
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,
lib/Date/Manip/Misc.pod view on Meta::CPAN
of this module.
Similarly for the 2007 changes in daylight saving time made in the United
States, Date::Manip was not affected. Date::Manip makes use of the
current time zone, but it gets that information from the operating system
the application is running on. If the operating system knows about the
new daylight saving time rules... so does Date::Manip.
=head1 WHAT DATES ARE DATE::MANIP USEFUL FOR?
Date::Manip applies to the Gregorian calendar. It does not support
alternative calendars (Hebrew, Mayan, etc.) so if you want to use
an alternative calendar, you'll need to look elsewhere.
The Gregorian calendar is a relatively recent innovation. Prior to it,
the Julian calendar was in use. The Julian calendar defined leap years as
every 4th year. This led to significant calendar drift over time (since
a year is NOT 365.25 days long). It was replaced by the Gregorian
calendar which improved the definition of leap years, and at that point,
the calendar was adjusted appropriately.
Date::Manip extrapolates the Gregorian calendar back to the year 0001
AD and forward to the year 9999 AD, but that does not necessarily mean
that the results are useful. As the world adopted the Gregorian
calendar, the dates using the Julian calendar had to be changed to fit
to account for the drift that had occurred. As such, the dates
produced by Date::Manip in an era where the Julian calendar was in use
do not accurately reflect the dates actually in use. In historical
context, the Julian calendar was in use until 1582 when the Gregorian
calendar was adopted by the Catholic church. Protestant countries did
not accept it until later; Germany and Netherlands in 1698, British
Empire in 1752, Russia in 1918, etc. Date::Manip is therefore not
equipped to truly deal with historical dates prior to about 1600, and
between 1600 and 1900, the calendar varied from country to country.
A second problem is that the Gregorian calendar is itself imperfect
and at some point may need to be corrected (though it's not clear that
this will happen... drift may now be accounted for using leap seconds
which means that the Gregorian calendar may be useful indefinitely).
No attempt is made to correct for the problems in the Gregorian
calendar for a couple reasons. First is that my great great great
grandchildren will be long dead before this begins to be a problem, so
it's not an immediate concern. Secondly, and even more importantly, I
don't know what the correction will be (if any) or when it will be
implemented, so I can safely ignore it.
There is some limitation on how dates can be expressed such that
Date::Manip can handle them correctly. Date::Manip stores the year
internally as a 4-digit number. This is obviously not a limit due to
the Gregorian calendar, but I needed a way to store the dates
internally, and the 4-digit year was chosen. I realize that the
4-digit limitation does create a time when it will break (quite
similar to those who chose a 2-digit representation set themselves up
for the Y2K problem). Frankly, I'm not too concerned about this since
that date is 8000 years in the future! Date::Manip won't exist then.
Perl won't exist then. And it's quite possible that the Gregorian
calendar won't exist then. That's a much different situation than the
Y2K choice in which programmers chose a representation that would
break within the lifetime of the programs they were writing.
Given the 4-digit limitation, Date::Manip definitely can't handle BC
dates, or dates past Dec 31, 9999. So Date::Manip works (in theory)
during the period Jan 1, 0001 to Dec 31, 9999. There are a few
caveats:
=over 4
=item B<Gregorian calendar issue>
In practical terms, Date::Manip deals with the Gregorian calendar, and
is most useful in the period that that calendar has been, or will be,
in effect. As explained above, the Gregorian calendar came into universal
acceptance in the early 1900's, and it should remain in use for the
foreseeable future.
So... in practical terms, Date::Manip is probably useful from
around 1900 through several thousand years from now.
=item B<First/last week>
In one part of the code (calculating week-of-year values), Date::Manip
references dates one week after and one week before the date actually
being worked on. As such, dates during the first week in the year 0001
fail (because a week before is in the year 1 BC), and those in the last
week in the year 9999 fail (because a week later is in 10,000).
No effort will be made to correct this because the added functionality
is simply not that important (to me), especially since the Gregorian
calendar doesn't really apply in either instance. To be absolutely
safe, I will state that Date::Manip works as described in this manual
during the period Feb 1, 0001 to Nov 30, 9999, and I will only support
dates within that range (i.e. if you submit a bug using a date that is
not in that range, I will will consider myself free to ignore it).
=item B<Leap seconds>
Date::Manip does NOT make use of the leap seconds in calculating time
intervals, so the difference between two times may not be strictly
accurate due to the addition of a leap second.
lib/Date/Manip/Recur.pm view on Meta::CPAN
my $dmb = $$dmt{'base'};
# Test the regular expression
my $rx = $self->_rx('every');
return 1 if ($string !~ $rx);
my($month,$week,$day,$last,$nth,$day_name,$day_abb,$mon_name,$mon_abb,$n,$y) =
@+{qw(month week day last nth day_name day_abb mon_name mon_abb n y)};
# Convert wordlist values to calendar values
my $dow;
if (defined($day_name) || defined($day_abb)) {
if (defined($day_name)) {
$dow = $$dmb{'data'}{'wordmatch'}{'day_name'}{lc($day_name)};
} else {
$dow = $$dmb{'data'}{'wordmatch'}{'day_abb'}{lc($day_abb)};
}
}
lib/Date/Manip/Recur.pod view on Meta::CPAN
0:0:0:1:12:0:0
refers to an event that occurs every 1 day, 12 hours.
The format of the interval is very simple. It is colon separated digits
only. No other characters are allowed.
The portion of the frequency that occur after an asterisk is called
the recurrence time (or rtime), and refers to a specific value (or
values) for that type of time element (i.e. exactly as it would appear
on a calendar or a clock). For example, if the frequency ends with
the rtime:
*12:0:0
then the recurring event occurs at 12:00:00 (noon).
For example:
0:0:0:2*12:30:0 every 2 days at 12:30 (each day)
lib/Date/Manip/Recur.pod view on Meta::CPAN
=item B<Non-zero day, non-zero week>
When both the day and week elements are non-zero, the day element
always refers to the day of week. Values must be in the range (1 to 7)
and no negative values are allowed.
The following tables shows all possible variations of the frequency
where this can happen (where day 4 = Thursday).
When the week is left of the asterisk, the interval is used to get the
weeks on the calendar containing a recurring date, and the day is used
to set the day of the week. The following are possible:
frequency meaning
1:2:3*4 every 1 year, 2 months, 3 weeks
on Thur
1:0:3*4 every 1 year, 3 weeks on Thur
0:2:3*4 every 2 months, 3 weeks on Thur
lib/Date/Manip/Recur.pod view on Meta::CPAN
single most important contribution to date/time handling in
Date::Manip.
When I first decided to add recurring events to Date::Manip, I first
came up with a list of common ways of specifying recurring events, and
then went looking for a notation that could be used to define them. I
was hoping for a notation that would be similar to cron notation, but
more powerful.
After looking in several specifications (including ISO 8601) and after
a discussion on a mailing list of calendar related topics, it appeared
that there was no concise, flexible notation for handling recurring
events that would handle all of the common forms I'd come up with.
So, as a matter of necessity, I set about inventing my own notation.
As I was looking at my list, it struck me that all of the parts which
specified a frequency were higher level (i.e. referred to a larger
unit of time) than those parts which specified a specific value (what
I've called the rtime). In other words, when the terms were laid out
from year down to seconds, the frequency part was always left of
specific values.
lib/Date/Manip/TZ.pod view on Meta::CPAN
common. If you do get this error, please refer to the section above
DETERMINING THE SYSTEM TIME ZONE for information about determining the
local time zone. I am also interested in hearing about this so that I
can update the default list of methods to be able to determine the
local time zone better.
=item B<Asia/Jerusalem time zone>
The Asia/Jerusalem time zone has a non-standard way of specifying
the start and end of Daylight Saving Time based on the Hebrew
calendar.
As a result, there is no way to specify a simple rule to define
time zone changes for all years in the future. As such, this module
supports all time zone changes currently specified in the zoneinfo
database (which currently goes to the year 2037) but does not attempt
to correctly handle zone changes beyond that date. As a result,
Date::Manip should not be used to parse dates in the Jerusalem
time zone that are far enough in the future that information is not
included in the current version of the zoneinfo database.
=item B<LMT and zzz abbreviations>
Both the LMT and zzz abbreviations are used in the zoneinfo databases.
LMT is use for most time zones for the times before the Gregorian
calendar was adopted, and zzz is used for a few where the time zone was
created and no description of dates prior to that are supported. Both
LMT and zzz are basically ignored in parsing dates (because there is
no reasonable way to determine which zone they are referring to), and
will be treated as the local time zone regardless.
=back
=head1 KNOWN BUGS
None known.
t/Manip5.cnf view on Meta::CPAN
# 1/5/1999 = A one-year-only holiday
# 1st Monday in Sep 1998 = Another one.
6/2/1999 = A special test holiday for 1999
################################
# EVENTS
################################
*EVENTS
# These are events that occur over a range of time. Useful for scheduling
# or calendar applications.
# Forms include
# date = event # Sets an event lasting 1 day or 1 hour (if no time)
2000-02-01 = Event1
2000-05-01 = Event2
2000-04-01-12:00:00 = Event3
# recur = event # Sets a recurring event lasting 1 day or 1 hour
t/OldEvents.cnf view on Meta::CPAN
################################
# EVENTS
################################
*EVENTS
# These are events that occur over a range of time. Useful for scheduling
# or calendar applications.
# Forms include
# date = event # Sets an event lasting 1 day or 1 hour (if no time)
2000-02-01 = Event1
2000-05-01 = Event2
2000-04-01-12:00:00 = Event3
# recur = event # Sets a recurring event lasting 1 day or 1 hour
( run in 0.824 second using v1.01-cache-2.11-cpan-5dc5da66d9d )