[ic] time tag with adjust in February bug?

Mike Heins mike at perusion.com
Mon Apr 1 15:02:37 UTC 2013

Quoting Paul Jordan (paul at gishnetwork.com):
> > 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.

I don't agree with this.

> 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.

You can't do month math in a consistent way.

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

Presumptions that you have to define yourself.

> 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.

There is no month math. If there was, you could add a month to Jan 31
and get Feb 31. Not possible. So you have to build your own set of
rules that you define if you want to have a treatment of that.

Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.765.253.4194  <mike at perusion.com>

Experience is what allows you to recognize a mistake the second
time you make it. -- unknown

More information about the interchange-users mailing list