[ic] time tag with adjust in February bug?
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
> Then the other components are handled normally. The above verification
> process is only needed after the Months processing.
> 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.
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