[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 Peter
> Sent: maandag 1 april 2013 14:35
> To: interchange-users at icdevgroup.org
> Subject: Re: [ic] time tag with adjust in February bug?
> 
> On 04/01/2013 10:30 PM, Gert van der Spoel wrote:
> > Let me take the bait, april's fool or not ... The 1 minute difference,
> not
> > sure ... But for the other ... Same issue you'd see if you take the date
> of
> > 31st May 2013 and do -1 month 1 day  ...
> >
> > What do you expect? 1 month down = April ... April has 30 days .. So 1
> month
> > 1 day you'd say is: 29 April ... Well it does not work like that I
> think,
> > because I tis fed to mktime 31-1 = 30   4-1=3 ... So that makes April
> 30th
> > .. And for the above Feb 30 = March 2 because it compensates the days.
> 
> Actually this is exactly what it's doing, you've hit the nail on the head.
> 
> > If you take 1st of June and do that -1 month -1 day it is fed to mktime
> as
> > 1-1=0   5-1=4     mktime then apparently says: Oh I get 0 that means I
> need
> > to take the last day of the previous month (30) and drop the month
> another
> > nodge (3) ... So 30th of April and all looks good.
> 
> Which is probably what you would want in this particular case.
> 
> > So the bottom line I'd say is: the time_adjust function is faulty as it
> does
> > not properly feed information to mktime
> 
> Being that I wrote the code I'm a bit partial to calling it faulty.  

I retract my calling it faulty :)

> It does exactly what you tell it to do, and the result of subtracting one
> month and one day is open to interpretation as to what the desired
> outcome is.  At the end of the day this is certainly not an "incorrect"
> outcome, it is just probably not the exact one that you would expect.
> 
> > .. As Mike says: " And you can't do
> > addition and subtraction by combining terms"  ... The code seems to say:
> Yes
> > you can ... But the reality is: with this code you cannot.
> 
> The code I wrote does introduce the concept of "months" into the
> equation, due to the fact that different months have different numbers
> of days this is not an exact science.  If you want to use months in your
> equation you get the result you get, if you don't then you won't have
> this problem, just like you would not have had it with the older code
> that did not recognize months.
> 
> That said, if anyone has a suggestion as to how to improve the function
> I am certainly open to it.

It was probably the reason why month had been left out. 31 March minus 1
Month would in general be considered 30 April .. So you'd first have to
calibrate the days in the month that once is minus-ing to and from that
point subtract the days ... 

31 March minus 1 month and 31 days ... pfew :)  That'd be 30 April minus 31
days ... That would be 28 February ... this year .. In other years it could
be 29 ... Not sure how easy it is going to be to make a piece of generic
code for this .. Especially if funny people will say -2monhs 39days etc .. 

You could also decide to document the current behaviour and then it just
does it the way it does it :)

 
> 
> Peter
> 
> _______________________________________________
> interchange-users mailing list
> interchange-users at icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users