1Date::Manip::Calc(3)  User Contributed Perl Documentation Date::Manip::Calc(3)
2
3
4

NAME

6       Date::Manip::Calc - describes date calculations
7

SYNOPSIS

9       Two objects (both of which are either Date::Manip::Date or
10       Date::Manip::Delta objects) may be used to creates a third object based
11       on those two.
12
13          $delta  = $date->calc($date2 [,$subtract] [,$mode]);
14
15          $date2  = $date->calc($delta [,$subtract]);
16          $date2  = $delta->calc($date1 [,$subtract]);
17
18          $delta3 = $delta1->calc($delta2 [,$subtract] [,$no_normalize]);
19

DESCRIPTION

21       This document describes the different types of calculations that can be
22       done using dates and deltas.  Date calculations are much more
23       complicated than they initially appear, so this document is fairly
24       large.
25
26       The complication in date calculations is due to the fact that it is
27       impossible to express some parts of a delta as an exact length.  Some
28       examples will illustrate this:
29
30       As an example, let's take two dates and determine how much time elapsed
31       between them:
32
33          Nov 3 2016 11:00:00
34          Dec 5 2016 12:00:00
35
36          Elapsed time: 770 hours
37
38       There are several ways to describe the time that elapsed.  The first
39       way is to give the difference exactly.  This is the exact delta.
40
41       An exact delta is always described in terms of hours, minutes, and
42       seconds.
43
44       The problem with this is that we don't think in terms of exact deltas.
45       We think in terms which cannot be expressed exactly.
46
47       For example, most people would look at those two dates and think:
48
49          Perceived: 1 month, 2 days, 1 hour
50
51       But the two dates:
52
53          Feb 3 2016 11:00:00
54          Mar 5 2016 12:00:00
55
56          Elapsed time: 745 hours
57          Perceived: 1 month, 2 days, 1 hour
58
59       Some fields in a delta do not have an exact length.  A year is usually
60       365 days long, but sometimes it is 366.  A month might be 28, 29, 30,
61       or 31 days long.
62
63       Perhaps the most unexpected difficulty is that days are not of constant
64       length.  Most people would define a day as 24 hours, but when you take
65       daylight saving time into account that definition produces unexpected
66       results.  The following calculation illustrates this:
67
68          Nov 5, 2011 02:30 EDT
69          + 24 hour
70
71          Result: Nov 6, 2011 01:30 EST
72
73       This immediately causes most people to redefine a day as the amount of
74       time between the same wall clock time.  For example, the amount of time
75       between noon one day and noon the next (regardless of daylight saving
76       time changes).
77
78       This definition doesn't work either.  For example:
79
80          Mar 12, 2011 02:30 EST
81          + 1 day (same time next day)
82
83          Result: Mar 13 02:30 EST
84
85       But that date does not exist!  Neither does:
86
87          Result: Mar 13 02:30 EDT
88
89       An alternate calculation could be:
90
91          Nov 5, 2011 01:30 EDT
92          + 1 day (same time next day)
93
94          Result: Nov 6, 01:30 EDT
95          Result: Nov 6, 01:30 EST
96
97       Both of those results exist.  Which result did you mean?  The first one
98       is probably correct (since it is 24 hours later), but an hour later,
99       you will have the same clock time again.
100
101       So, the same time next day definition doesn't work at all for some
102       dates (during a 'spring forward' type daylight saving time transition)
103       and is ambiguous for others (during a 'fall back' type daylight saving
104       time transition).
105
106       Calculations involving exact deltas are unambiguous in all cases.
107
108       A second class of delta is called a semi-exact delta, and these add
109       days (and weeks) to the delta, and treats days as a "same time next
110       day" at all times except the two cases where the resulting date falls
111       in the period where a daylight saving time transition is occurring.
112       Then it falls back to the 24 hour definition.
113
114       A final class of delta is an approximate delta which includes all of
115       the fields (years and months).  This allows Date::Manip to handle
116       deltas in a way that is consistent with how most people perceive the
117       elapsed time.  It should be noted that there is some uncertaintly there
118       as not everyone's definition of how a delta is perceived is the same,
119       but in general, they should be closer to what most people think of.
120

TYPES OF CALCULATIONS

122       This document describes the different types of calculations.
123       Calculations involve two types of Date::Manip objects: dates and
124       deltas. These are described in the Date::Manip::Date and
125       Date::Manip::Delta manuals respectively.
126
127       Two objects (two dates, two deltas, or one of each) are used.  In all
128       cases, if a second object is not passed in, undef is returned.
129
130       There are 3 types of calculations:
131
132       Date/Date calculations
133           A calculation involving 2 dates is used to determine the amount of
134           time (the delta) between them.
135
136              $delta  = $date1->calc($date2 [,$subtract] [,$mode]);
137
138           Two dates can be worked with and a delta will be produced which is
139           the amount of time between the two dates.
140
141           $date1 and $date2 are Date::Manip::Date objects with valid dates.
142           The Date::Manip::Delta object returned is the amount of time
143           between them. If $subtract is not passed in (or is 0), the delta
144           produced is:
145
146              DELTA = DATE2 - DATE1
147
148           If $subtract is non-zero, the delta produced is:
149
150              DELTA = DATE1 - DATE2
151
152           The $subtract argument has special importance when doing
153           approximate calculations, and this is described below.
154
155           If either date is invalid, a delta object will be returned which
156           has an error associated with it.
157
158           The $mode argument describes the type of delta that is produced and
159           is described below in "MODE".
160
161       Date/Delta calculations
162           Date/delta calculations can be performed using either a
163           Date::Manip::Date or Date::Manip::Delta object as the primary
164           object:
165
166              $date2  = $date1->calc($delta [,$subtract]);
167              $date2  = $delta->calc($date1 [,$subtract]);
168
169           A date and delta can be combined to yield a date that is the given
170           amount of time before or after it.
171
172           $date1 and $delta are Date::Manip::Date and Date::Manip::Delta
173           objects respectively. A new Date::Manip::Date object is produced.
174           If either $date1 or $delta are invalid, the new date object will
175           have an error associated with it.
176
177           Both of the calls above perform the same function and produce
178           exactly the same results.
179
180           If $subtract is not passed in, or is 0, the resulting date is
181           formed as:
182
183              DATE2 = DATE1 + DELTA
184
185           If $subtract is non-zero, the resulting date is:
186
187              DATE2 = DATE1 - DELTA
188
189           The $subtract argument has special importance when doing
190           approximate calculations, and this is described below in
191           "SUBTRACTION".
192
193       Delta/Delta calculations
194           Delta/delta calculations can be performed to add two amounts of
195           time together, or subtract them.
196
197              $delta3 = $delta1->calc($delta2 [,$subtract] [,$no_normalize]);
198
199           If $subtract is not passed in, or is 0, the resulting delta formed
200           is:
201
202              DELTA3 = DELTA1 + DELTA2
203
204           If $subtract is non-zero, then the resulting delta is:
205
206              DELTA3 = DELTA1 - DELTA2
207
208           $delta1 and $delta2 are valid Date::Manip::Delta objects, and a new
209           Date::Manip::Delta object is produced.
210
211           $no_normalize can be the string 'nonormalize' or a non-zero value
212           (in which case $subtract MUST be entered, even if it is 0).
213

MODE

215       Date::Manip calculations can be divided into two different categories:
216       business and non-business; and within those are three sub-categories:
217       exact, semi-exact, and approximate.
218
219       Business and non-business calculations
220           A business calculation is one where the length of the day is
221           determined by the length of the work day, and only business days
222           (i.e. days in which business is conducted) count. Holidays and
223           weekends are omitted (though there is some flexibility in defining
224           what exactly constitutes the work week as described in the
225           Date::Manip::Config manual). This is described in more detail below
226           in "BUSINESS MODE CONSIDERATIONS".
227
228           A non-business mode calculation is the normal type of calculation
229           where no days are ignored, and all days are full length.
230
231       Exact, semi-exact, and approximate calculations
232           An exact calculation is one in which the delta used (or produced)
233           is an exact delta.  An exact delta is described in more detail in
234           the Date::Manip::Delta manual, but the short explanation is that it
235           is a delta which only involves fields of an exactly known length
236           (hours, minutes, and seconds).  Business deltas also include days
237           in the exact part.  The value of all other fields in the delta will
238           be zero.
239
240           A semi-exact calculation is one in which the deltas used (or
241           produced) is a semi-exact delta.  This is also described in the
242           Date::Manip::Delta manual, but the short explanation is that it
243           includes days and weeks (for standard calculations) or weeks (for
244           business calculations) in addition to the exact fields.  A semi-
245           exact day is defined as the same clock time on two successive days.
246           So noon to noon is 1 day (even though it may not be exactly 24
247           hours due to a daylight saving time transition).  A week is defined
248           as 7 days. This is described in more detail below.
249
250           An approximate calculation is one in which the deltas used (or
251           produced) are approximate, and may include any of the fields.
252
253       In date-delta and delta-delta calculations, the mode of the calculation
254       will be determined automatically by the delta. In the case of date-date
255       calculations, the mode is supplied as an argument.
256
257       Mode in date-date calculations
258           When doing a date-date calculation, the following call is used:
259
260              $delta = $date1->calc($date2 [,$subtract] [,$mode]);
261
262           $mode defaults to "exact". The delta produced will be be either a
263           business or non-business delta; exact, semi-exact, or approximate,
264           as specified by $mode.
265
266           Currently, the possible values that $mode can have are:
267
268              exact    : an exact, non-business calculation
269              semi     : a semi-exact, non-business calculation
270              approx   : an approximate, non-business calculation
271
272              business : an exact, business calculation
273              bsemi    : a semi-exact, business calculation
274              bapprox  : an approximate, business calculation
275
276       Mode in date-delta calculations
277           When doing calculations of a date and a delta:
278
279              $date2 = $date1->calc($delta [,$subtract]);
280              $date2 = $delta->calc($date1 [,$subtract]);
281
282           the mode is not passed in. It is determined exclusively by the
283           delta. If $delta is a business delta, A business calculation is
284           done. If $delta is a non-business delta, a non-business calculation
285           will be done.
286
287           The $delta will also be classified as exact, semi-exact, or
288           approximate based on which fields are non-zero.
289
290       Mode in delta-delta calculations
291           When doing calculations with two deltas:
292
293              $delta3 = $delta1->calc($delta2 [,$subtract]);
294
295           the mode is not passed in. It is determined by the two deltas.
296
297           If both deltas are business mode, or both are non-business mode, a
298           new delta will be produced of the same type.
299
300           It one of the deltas is a business mode and the other is not, the
301           resulting delta will have an error condition since there is no
302           direct correlation between the two types of deltas. Even though it
303           would be easy to add the two together, it would be impossible to
304           come up with a result that is meaningful.
305
306           If both deltas are exact, semi-exact, or approximate, the resulting
307           delta is the same. If one delta is approximate and one is not, then
308           the resulting delta is approximate.  It is NOT treated as an error.
309           Likewise, if one is semi-exact and the other exact, a semi-exact
310           delta is produced.
311

TIMEZONE CONSIDERATIONS

313       date-date calculations
314           When doing a business calculation, both dates must be in the same
315           time zone or an error is produced.
316
317           For non-business calculations, when calculating the difference
318           between two dates in different time zones, $date2 will be converted
319           to the same timezone as $date1 and the returned date will be in
320           this timezone.
321
322       date-delta calculations
323           When adding a delta to a date, the resulting date will be in the
324           same time zone as the original date.
325
326       delta-delta calculations
327           No timezone information applies.
328
329       It should also be noted that daylight saving time considerations are
330       currently ignored when doing business calculations.  In common usage,
331       daylight saving time changes occurs outside of the business day, so the
332       business day length is constant.  As a result, daylight saving time is
333       ignored.
334

BUSINESS MODE CONSIDERATIONS

336       In order to correctly do business mode calculations, a config file
337       should exist which contains the section defining holidays (otherwise,
338       weekends will be ignored, but all other days will be counted as
339       business days). This is documented below, and in the
340       Date::Manip::Config section of the documentation.  Some config
341       variables (namely WorkWeekBeg, WorkWeekEnd, WorkDayBeg, WorkDayEnd, and
342       WorkDay24Hr) defined the length of the work week and work day.
343
344       If the workday is defined as 08:00 to 18:00, a work week consisting of
345       Mon-Sat, and the standard (American) holidays, then from Tuesday at
346       12:00 to the following Monday at 14:00 is 5 days and 2 hours.  If the
347       "end" of the day is reached in a calculation, it automatically switches
348       to the next day.  So, Tuesday at 12:00 plus 6 hours is Wednesday at
349       08:00 (provided Wed is not a holiday).  Also, a date that is not during
350       a workday automatically becomes the start of the next workday.  So,
351       Sunday 12:00 and Monday at 03:00 both automatically becomes Monday at
352       08:00 (provided Monday is not a holiday).
353
354       Note that a business week is treated the same as an exact week (i.e.
355       from Tuesday to Tuesday, regardless of holidays).  Because this means
356       that the relationship between days and weeks is NOT unambiguous, when a
357       semi-exact delta is produced from two dates, it will be in terms of
358       d/h/mn/s (i.e. no week field).
359
360       Anyone using business mode is going to notice a few quirks about it
361       which should be explained.  When I designed business mode, I had in
362       mind what a business which promises 1 business day turnaround really
363       means.
364
365       If you do a business calculation (with the workday set to 9:00-17:00),
366       you will get the following:
367
368          Saturday at noon + 1 business day = Tuesday at 9:00
369          Saturday at noon - 1 business day = Friday at 9:00
370
371       What does this mean?
372
373       As an example, say I use a business that works 9-5 and they have a drop
374       box so I can drop things off over the weekend and they promise 1
375       business day turnaround.  If I drop something off Friday night,
376       Saturday, or Sunday, it doesn't matter.  They're going to get started
377       on it Monday morning.  It'll be 1 business day to finish the job, so
378       the earliest I can expect it to be done is around 17:00 Monday or 9:00
379       Tuesday morning.  Unfortunately, there is some ambiguity as to what day
380       17:00 really falls on, similar to the ambiguity that occurs when you
381       ask what day midnight falls on.  Although it's not the only answer,
382       Date::Manip treats midnight as the beginning of a day rather than the
383       end of one.  In the same way, 17:00 is equivalent to 9:00 the next day
384       and any time the date calculations encounter 17:00, it automatically
385       switch to 9:00 the next day.  Although this introduces some quirks, I
386       think this is justified.  I also think that it is the way most people
387       think of it. If I drop something off first thing Monday morning, I
388       would expect to pick it up first thing Tuesday if there is 1 business
389       day turnaround.
390
391       Equivalently, if I want a job to be finished on Saturday (despite the
392       fact that I cannot pick it up since the business is closed), I have to
393       drop it off no later than Friday at 9:00.  That gives them a full
394       business day to finish it off.  Of course, I could just as easily drop
395       it off at 17:00 Thursday, or any time between then and 9:00 Friday.
396       Again, it's a matter of treating 17:00 as ambiguous.
397
398       So Saturday + 1 business day = Tuesday at 9:00 (which means anything
399       from Monday 17:00 to Tuesday 9:00), but Monday at 9:01 + 1 business day
400       = Tuesday at 9:01 which is unambiguous.
401
402       It should be noted that when adding years, months, and weeks, the
403       business day is ignored.  Once they've been added, the resulting date
404       is forced to be a business time (i.e. it moves to the start of the next
405       business day if it wasn't one already) before proceeding with the days,
406       hours, minutes, and seconds part.
407

EXACT, SEMI-EXACT, AND APPROXIMATE DATE/DELTA CALCULATIONS

409       This section contains more details about exactly how exact, semi-exact,
410       and approximate calculations are performed for date/delta calculations.
411
412       All calculations make use of some exact quantities, including:
413
414         1 year   = 12 months
415         1 week   = 7 days
416         1 hour   = 60 minutes
417         1 minute = 60 seconds
418
419       This leaves two relationships which are not exact:
420
421         1 month  = ? days
422         1 day    = ? hours
423
424       For non-business calculations, a day is usually 24 hours long. Due to
425       daylight saving time transitions which might make a day be 23 or 25
426       hours long (or in some cases, some other length), the relation is not
427       exact.  Whenever possible, a day is actually measured as the same time
428       on two days (i.e. Tuesday at noon to Wednesday at noon) even if that
429       period is not precisely 24 hours.  For business calculations, a days
430       length is determined by the length of the work day and is known
431       exactly.
432
433       Exact calculations involve ONLY quantities of time with a known length,
434       so there is no ambiguity in them.
435
436       Approximate and semi-exact calculations involve variable length fields,
437       and so they must be treated specially.
438
439       In order to do an approximate or semi-exact calculation, the delta is
440       added to a date in pieces, where the fields in each piece have an exact
441       and known relationship.
442
443       For a non-business calculation, a calculation occurs in the following
444       steps:
445
446         year/month fields added
447         week/day fields added
448         hour/minute/second fields added
449
450       For a business calculation, the steps are:
451
452         year/month fields added
453         week field added
454         day field added
455         hour/minute/second fields added
456
457       After each step, a valid date must be present, or it will be adjusted
458       before proceeding to the next step.  Note however that for business
459       calculations, the first step must produce a valid date, but not
460       necessarily a business date.  The second step will produce a valid
461       business date.
462
463       A series of examples will illustrate this.
464
465       A date and non-business approximate delta
466              date  = Mar 31 2001 at 12:00:00
467              delta = 1 year, 1 month, 1 day, 1 hour
468
469           First, the year/month fields are added without modifying any other
470           field.  This would produce:
471
472              Apr 31, 2002 at 12:00
473
474           which is not valid.  Any time the year/month fields produce a day
475           past the end of the month, the result is 'truncated' to the last
476           day of the month, so this produces:
477
478              Apr 30, 2002 at 12:00
479
480           Next the week/day fields are added producing:
481
482              May 1, 2002 at 12:00
483
484           and finally, the exact fields (hour/minute/second) are added to
485           produce:
486
487              May 1, 2002 at 13:00
488
489       A simple business calculation
490           Assuming a normal Monday-Friday work week from 8:00 - 17:00:
491
492              date  = Wed, Nov 23, 2011 at 12:00
493              delta = 1 week, 1 day, 1 hour
494
495           First, the week field is added:
496
497              Wed, Nov 30, 2011 at 12:00
498
499           Then the day field is added:
500
501              Thu, Dec 1, 2011 at 12:00
502
503           Then the exact fields are added:
504
505              Thu, Dec 1, 2011 at 13:00
506
507       A business example where a holiday impacts it
508           In America, Jul 4 is a holiday, so Mon, Jul 4, 2011 is not a work
509           day.
510
511              date  = Mon, Jun 27, 2011 at 12:00
512              delta = 1 week, 1 day, 1 hour
513
514           First, the week field is added:
515
516              Mon, Jul 4, 2011 at 12:00
517
518           Since that is not a work day, it immediately becomes:
519
520              Tue, Jul 5, 2011 at 8:00
521
522           Then the day field is added:
523
524              Wed, Jul 6, 2011 at 8:00
525
526           and finally the remaining fields:
527
528              Wed, Jul 6, 2011 at 9:00
529
530       Calculation where daylight savings time impacts it (fall example)
531           In the America/New_York timezone (Eastern time), on November 6,
532           2011, the following time change occurred:
533
534              2011-11-06 02:00  EDT  => 2011-11-06 01:00  EST
535
536           Three simple calculations illustrate how this is handled:
537
538              date  = 2011-11-05 02:30 EDT
539              delta = 1 day
540
541           Adding the day produces:
542
543              2011-11-06 02:30  EDT
544
545           which is valid, so that is the result.
546
547           Similarly:
548
549              date  = 2011-11-07 02:30 EST
550              delta = -1 day
551
552           produces:
553
554              2011-11-06 02:30 EST
555
556           which is valid.
557
558           Finally:
559
560              date  = 2011-11-05 02:30 EDT
561              delta = 2 days
562
563           produces:
564
565              2011-11-07 02:30  EST
566
567           The calculation will preserve the savings time where possible so
568           the resulting day will have the same offset from UTC.  If that is
569           not possible, but the resulting day is valid in the other offset,
570           that will be used instead.
571
572       Calculation where daylight savings time impacts it (spring example)
573           In the America/New_York timezone (Eastern time), on March 13, the
574           following time change occurred:
575
576              2011-03-13 02:00  EST  => 2011-03-13 03:00  EDT
577
578           In this case, a calculation may produce an invalid date.
579
580              date  = 2011-03-12 02:30 EST
581              delta = 1 day
582
583           produces:
584
585              2011-03-13 02:30 EST
586
587           This is not valid.  Neither is:
588
589              2011-03-13 02:30 EDT
590
591           In this case, the calculation will be redone converting days to
592           24-hour periods, so the calculation becomes:
593
594              date  = 2011-03-12 02:30 EST
595              delta = 24 hours
596
597           which will produce a valid date:
598
599              2011-03-13 03:30 EDT
600

EXACT, SEMI-EXACT, AND APPROXIMATE DATE/DATE CALCULATIONS

602       This section contains more details about exactly how exact, semi-exact,
603       and approximate calculations are performed for date/date calculations.
604
605       When calculating the delta between two dates, the delta may take
606       different forms depending on the mode passed in. An exact calculation
607       will produce a delta which included only exact fields.  A semi-exact
608       calculation may produce a semi-exact delta, and an approximate
609       calculation may produce an approximate delta.  Note that if the two
610       dates are close enough together, an exact delta will be produced (even
611       if the mode is semi-exact or approximate), or it may produce a semi-
612       exact delta in approximate mode.
613
614       For example, the two dates "Mar 12 1995 12:00" and "Apr 13 1995 12:00"
615       would have an exact delta of "744 hours", and a semi-exact delta of "31
616       days".  It would have an approximate delta of "1 month 1 day".
617
618       Two dates, "Mar 31 12:00" and "Apr 30 12:00" would have deltas "720
619       hours" (exact), "30 days" (semi-exact) or "1 month" (approximate).
620
621       Approximate mode is a more human way of looking at things (you'd say 1
622       month and 2 days more often then 33 days), but it is less meaningful in
623       terms of absolute time.
624
625       One thing to remember is that an exact delta is exactly the amount of
626       time that has passed, including all effects of daylight saving time.
627       Semi-exact and approximate deltas usually ignore the affects of
628       daylight saving time.
629

SUBTRACTION

631       In exact and semi-exact calculations, and in delta-delta calculations,
632       the the $subtract argument is easy to understand.  When working with an
633       approximate delta however (either when adding an approximate delta to a
634       date, or when taking two dates to get an approximate delta), there is a
635       degree of uncertainty in how the calculation is done, and the $subtract
636       argument is used to specify exactly how the approximate delta is to be
637       use. An example illustrates this quite well.
638
639       If you take the date Jan 4, 2000 and subtract a delta of "1 month 1
640       week" from it, you end up with Nov 27, 1999 (Jan 4, 2000 minus 1 month
641       is Dec 4, 1999; minus 1 week is Nov 27, 1999). But Nov 27, 1999 plus a
642       delta of "1 month 1 week" is Jan 3, 2000 (Nov 27, 1999 plus 1 month is
643       Dec 27, 1999; plus 1 week is Jan 3, 2000).
644
645       In other words the approximate delta (but NOT the exact or semi-exact
646       delta) is different depending on whether you move from earlier date to
647       the later date, or vice versa. And depending on what you are
648       calculating, both are useful.
649
650       In order to resolve this, the $subtract argument can take on the values
651       0, 1, or 2, and have different meanings.
652
653       $subtract in approximate date-date calculations
654           In the call:
655
656              $delta = $date1->calc($date2,$subtract,"approx");
657
658           if $subtract is 0, the resulting delta can be added to $date1 to
659           get $date2. Obviously $delta may still be negative (if $date2 comes
660           before $date1).
661
662           If $subtract is 1, the resulting delta can be subtracted from
663           $date1 to get $date2 (the deltas from these two are identical
664           except for having an opposite sign).
665
666           If $subtract is 2, the resulting delta can be added to $date2 to
667           get $date1. In other words, the following are identical:
668
669              $delta = $date1->calc($date2,2,"approx");
670              $delta = $date2->calc($date1,"approx");
671
672       $subtract in approximate date-delta calculations
673           In the call:
674
675              $date2 = $date1->calc($delta,$subtract);
676
677           If $subtract is 0, the resulting date is determined by adding
678           $delta to $date1.
679
680           If $subtract is 1, the resulting date is determined by subtracting
681           $delta from $date1.
682
683           If $subtract is 2, the resulting date is the date which $delta can
684           be added to to get $date1.
685
686           For business mode calculations, $date1 will first be adjusted to be
687           a valid work day (if it isn't already), so this may lead to non-
688           intuitive results.
689
690           In some cases, it is impossible to do a calculation with $subtract
691           = 2.  As an example, if the date is "Dec 31" and the delta is "1
692           month", there is no date which you can add "1 month" to to get "Dec
693           31".  When this occurs, the date returned has an error flag.
694

APPROXIMATE DATE/DATE CALCULATION

696       There are two different ways to look at the approximate delta between
697       two dates.
698
699       In Date::Manip 5.xx, the approximate delta between the two dates:
700
701          Jan 10 1996 noon
702          Jan  7 1998 noon
703
704       was 1:11:4:0:0:0:0 (or 1 year, 11 months, 4 weeks).  In calculating
705       this, the first date was adjusted as far as it could go towards the
706       second date without going past it with each unit starting with the
707       years and ending with the seconds.
708
709       This gave a strictly positive or negative delta, but it isn't actually
710       how most people would think of the delta.
711
712       As of Date::Manip 6.0, the delta is 2:0:0:-3:0:0:0 (or 2 years minus 3
713       days). Although this leads to mixed-sign deltas, it is actually how
714       more people would think about the delta. It has the additional
715       advantage of being easier to calculate.
716
717       For non-business mode calculations, the year/month part of the
718       approximate delta will move a date from the year/month of the first
719       date into the year/month of the second date. The remainder of the delta
720       will adjust the days/hours/minutes/seconds as appropriate.
721
722       For approximate business mode calculations, the year, date, and week
723       parts will be done approximately, and the remainder will be done
724       exactly.
725

KNOWN BUGS

727       None known.
728

BUGS AND QUESTIONS

730       Please refer to the Date::Manip::Problems documentation for information
731       on submitting bug reports or questions to the author.
732

SEE ALSO

734       Date::Manip        - main module documentation
735

LICENSE

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

AUTHOR

741       Sullivan Beck (sbeck@cpan.org)
742
743
744
745perl v5.30.2                      2020-04-27              Date::Manip::Calc(3)
Impressum