[ic] time tag with adjust in February bug?

[Gert van der Spoel]

> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org [mailto:interchange-users-
> bounces at icdevgroup.org] On Behalf Of Mike Heins
> Sent: maandag 1 april 2013 15:00
> To: interchange-users at icdevgroup.org
> Subject: Re: [ic] time tag with adjust in February bug?
> 
> Quoting Peter (peter at pajamian.dhs.org):
> > On 04/01/2013 04:36 PM, Mike Heins wrote:
> > >There is no "month". 1m is one minute, the "onth" makes no difference.
> > >And you can't do addition and subtraction by combining terms...
> >
> > Actually there is, added in May of 2009.  Check the adjust_time()
> > function in Utils.pm
> >
> > >This is April Fool's on European time, no?
> >
> > Nope, even though it was April 1st in New Zealand at the time.
> >
> 
> I am afraid I was not aware of this transition in code, I had thought
> that all of this type of code used Vend::Config::time_to_seconds().
> One is, of course, at the mercy of the mktime() function, and it is
> not at all clear what happens when you alter multiple members. March
> and February are particularly picky in that area, as Feb. 30 is not
> something that can be represented.
> 
> 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.

That was my initial thought but nope ... 31-5 minus 1 month makes 1-5 ... 
It would need adjusting at this point already ...