[ic] time tag with adjust in February bug?

Paul Jordan paul at gishnetwork.com
Mon Apr 1 14:09:58 UTC 2013


> users-bounces at icdevgroup.org] On Behalf Of 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 

That last sentence is wrong. You original intention would always be to stay
with the earliest valid date no matter which direction you are going.

Paul





More information about the interchange-users mailing list