[ic] time tag with adjust in February bug?

[Paul Jordan]

> users-bounces at icdevgroup.org] On Behalf Of Mike Heins
> Quoting Peter (peter at pajamian.dhs.org):
> > On 04/02/2013 01:00 AM, Mike Heins wrote:
> > >The only way to do this properly would be to run mktime after each
> > >atom of adjustment, generating a new @times array, and then apply the
> > >next. Even then, you may not get what you think you are going to get.
> >
> > Right, even adjusting just the month you get:
> >
> > 31st Mar - 1 month = 31st Feb which gets corrected to 3rd of Mar (or
> > 2nd if it's a leap year).  Fail already.
> >
> > The only way I can think of to do this "correctly" is to use DateTime.
> > What I could do is check for the existence of DateTime and use that if
> > it's present, and fall back to the existing code otherwise.
> 
> Yes, that makes sense. Originally, I didn't want to deal with months as a
> standard function precisely because the behavior of months is truly
> undefined. Even the date modules Date::Calc and DateTime, either of which


But a month is well defined and (to Peter), it is an exact science. Months
is any number of months, not any number of days. It is a calendar term, and
not a representation of a calculable amount of days except in the most
casual ways. No definition ever gives it a set amount of days either, but
defines it as one of the twelve portions of the calendar year.

If one wanted to subtract 40 days, they'd say subtract 40 days, not subtract
one month 10 days - as that clearly makes presumptions. 

It seems to me that when combining terms, we'd operate on the largest to the
smallest. Minus 1 month from the month's position (date wise, not
mathematically), then that date is verified, if it is *not* found to be an
accurate date, one day is decremented until it is found to be valid. 

I say this because since the only conflicts happen at the end of months,
then when adding or subtracting months, if you come to an invalid time, your
original intention would always be the most valid date closest to the
original date - because your intention would never be to add 6 months when
you asked to add 5 - it would always be to remain in the 5th month - no
more.

Then the other components are handled normally. The above verification
process is only needed after the Months processing. 

Examples:
  March 31 - 1 month = Last day of Feb
  January 30 + 1 month = Last day of Feb
  January 31 + 1 month = Last day of Feb

The reason this is like this is because we are dealing with the term of a
Month, and not an amount of days.

Minus a month does not mean:
   - let's decrement the amount of days in this month
   - Let's decrement 31, 30, 29, or 28 days

I cannot comment on DST, but it seems to me the only issue is with Months,
as that is the only position that would be mathematically variable.


Paul