If you value your time at $10/hour the examples included in MBS that actually exercise the code Christian incorporates in the plugin will be more valuable (relative to license cost) to your understanding than anything written in this thread before Tim showed up. And get this… You can download the MBS plugins and examples for FREEE and use then to your heart’s content within the IDE. You might even learn the salient issues about subtracting dates from an example!
There is another discussion this morning where someone mentioned that code snippets are (I’m paraphrasing) basically a cruel joke, and the right way to share code is in modules. I’d add that test projects that exercise the modules bring forth assumptions that are very important but not so clear with simple code snippets. This is, BTW, why I think the Xippets site is at best a toy, though more likely unhelpful. But I digress… You will find that the 3rd party add-on developers selling stuff generally go all out with the sample projects because there is tremendous explanatory value in doing so. I don’t see much of that from the “do it ourselves for free” crowd here. I do see a lot of problematic code snippets shared in the forums. Hurray for the community!
[quote=126414:@Dave S]Wow… ignorant now am I?
Because I propose a learning experience as opposed to as Michel called it a “instant coffee” approach…
Sure MBS has its place… for those where time is money, but many of us (and I bet the OP is one), like to expand OUR knowledge.
Am sorry to see the “community spirit” of this forum begin to fail so quickly.
And in my opinion if you give 100 programmers a binary search problem. and all 100 don’t come up with almost identical answers than I would fire them all. (HI+LO)/2 … seriously?[/quote]
Hi Dave,
All (or Almost All) know that this forum is ignorant, do not worry my friend .
Brad, you may have taken too many pills this time.
Where did I say anything against Tim ? How have I in any way cheered with any mob ?
Plugins and third party tools are an excellent way for professionals not to waste time.
=>BUT<=
The very reason for this forum to exist is to EXCHANGE (emphasis on bidirectional communication) knowledge (not just comments). And this exchange takes place between professionals and amateurs, specialists and beginners. This, in my humble opinion, implies a reasoned effort on both sides to show tolerance. I frankly do not share the view of some anti-plugin passionarias around here. It is as ridiculous as refusing to use Xojo under the pretext that Objective-C is free. It does not justify in any way attempts to put down discussions about pure Xojo code as some sort of drama. Or to discount snippets as toys. Discussing algorithms and methods and posting code is dead on target for what this forum stands for. Just as pointing out ready-made plugin solutions exist.
Whatever pathos and unnecessary aggressivity has been added to this discussion should simply be disregarded as off topic. Let the OP be the judge of what is helpful. One thing is for sure : fighting is NOT helpful.
Notice still… No thank you to Tim or to Christian for providing working solutions. There are plenty of people on the forums who could help with pure Xojo code sooner without a lot of effort. But notice that it’s more important to slap Christian for offering something for sale than it is to thank someone who contributes a working solution. This is much more the rule than the exception in discussions on this forum. I’m sorry that pointing that out makes some of you uncomfortable. In this post and my posts above, I give several constructive hints how you could offer honey to people who can actually help you with working solutions here. Here’s another hint… The “you shouldn’t pay for it” attitude is an impediment to people who can help wanting to help. #Truth
One of the issues is that “year” and “month” are not a single fixed number - they do vary.
Months are not consistently long nor are years and they vary in length based on leap years.
So measuring days & weeks is easy - count them up and divide by 7 you have days & weeks.
A week is always 7 days.
After that it gets weird and open to interpretation.
Say you have today being “Mar 31, 2016”
Now what is “one month prior” ? Feb 31 - which is non sense.
Or if today is “Feb 29, 2016” - what is one year prior as there is no Feb 29, 2015.
Any time you have a date that has no corresponding date in a prior year or month you have a problem that has to be interpreted according to some heuristic.
Therein lies the ambiguity in measuring elapsed time in years , months & days.
There is ambiguity.
[quote=126441:@Norman Palardy]One of the issues is that “year” and “month” are not a single fixed number - they do vary.
Months are not consistently long nor are years and they vary in length based on leap years.
So measuring days & weeks is easy - count them up and divide by 7 you have days & weeks.
A week is always 7 days.
After that it gets weird and open to interpretation.
Say you have today being “Mar 31, 2016”
Now what is “one month prior” ? Feb 31 - which is non sense.
Or if today is “Feb 29, 2016” - what is one year prior as there is no Feb 29, 2015.
Any time you have a date that has no corresponding date in a prior year or month you have a problem that has to be interpreted according to some heuristic.
Therein lies the ambiguity in measuring elapsed time in years , months & days.
There is ambiguity.[/quote]
No - really - never knew that - wow - learnt something there
Brad, I have no idea what can have happened to you to make you so vindictive. I agree that Christian does an outstanding job informing forum members about solutions available. And sometimes, he offers solutions that do not require his plugins, like the way to play audio he posted recently in the Web channel. Tim is constant in his efforts to enlighten the forum, and I appreciate very much his insight. Sure, let them be thanked. But am sorry, I see no malevolent intent here.
For the record, I am a satisfied customer of MBS. And I use his products in my apps. But I still appreciate home made cooking, and enjoy experimenting with my own code. It is good for the little grey cells.
Michel, this attitude poisoned the discussion at the top. It’s uncalled for:
[quote]No need to buy an expensive 3rd party plugin to do simple math.
[/quote]
Couple it with a “solution” that doesn’t even work from the same guy, and I honestly can’t think of a reason why anyone who offers anything for sale to this community would want to do anything but just sit back and watch amateur hour ensue. Far more entertaining than vindictive. I like how after Tim posts something that does work how the same guy now wants an explanation about why his code doesn’t work. I suppose it will come before a thank you for 2 answers that solve the OP’s problem, but it shouldn’t.
I have no beef with you, Michel. Dave should apologize for poisoning the discussion though.
Dave, the problem is, as Norman pointed out, that months have varying numbers of days, so simply calculating the difference in days (or seconds) is insufficient to answer the question, “How many months?” The human looks at 2014-06-20 to 2014-08-05 and says, “1 month, 16 days”. That span could actually include a varying number of actual days, but it’s still “1 month plus” and that’s where the problem lies. If you take the span from 2014-02-20 to 2014-04-05, that’s still “1 month, 16 days”, but the span contains 2 fewer actual days. Secondarily, taking that span of days and superimposing it on 1904-01-01 creates yet another layer of error, again due to the varying number of days in a month, plus a leap year to add to the confusion.
Please note: I did not rigorously test my solution, it may contain bugs, too. I present is as illustrative of an approach to the problem, not a completed solution. I only spent about 5 minutes on it, so take it with a grain of salt.
[quote=126441:@Norman Palardy]One of the issues is that “year” and “month” are not a single fixed number - they do vary.
Months are not consistently long nor are years and they vary in length based on leap years.
So measuring days & weeks is easy - count them up and divide by 7 you have days & weeks.
A week is always 7 days.
After that it gets weird and open to interpretation.
Say you have today being “Mar 31, 2016”
Now what is “one month prior” ? Feb 31 - which is non sense.
Or if today is “Feb 29, 2016” - what is one year prior as there is no Feb 29, 2015.
Any time you have a date that has no corresponding date in a prior year or month you have a problem that has to be interpreted according to some heuristic.
Therein lies the ambiguity in measuring elapsed time in years , months & days.
There is ambiguity.[/quote]
It should be possible to solve ;
The only variable length month is February, because of the leap year. Xojo calculates very well the number of days in February.
Function JoursDuMois(y as integer, m as integer) As integer
dim olddate as new date(y,m,1)
dim newdate as new date(y,m+1,1)
newdate.day = newdate.day-1
return newdate.day-olddate.day
End Function
What? A question was asked… I offered a solution (perhaps not a perfect one)… but not sure where “poison” comes in?
And it is (and always will be) that plugins have there place… and I don’t this this is one of them… When this forum degrades to the point where an opinion is “poison”, then …
I’ll just end with this… Christian didn’t claim the math was simple and provide a non-working solution. Nor did he leave an edge case as an exercise to the reader. Those two facts ought to establish that the value incorporated into his solution sets a high bar. Even for such an “easy” problem.
Still no thank you from the peanut gallery to Christian or Tim. Or Norman for that matter. No apology to Christian for the rude dismissal of his solution. We see how this works.
We all have at least once assumed a problem was “simple math”, to discover later that it was much more complex. As this thread was starting to show thanks to Tim and Norman, there is more about difference between dates over one year than simple subtractions.
I find this challenge interesting, and have no doubt perfectionist Christian spent quite a bit of work to have DateDifferenceMBS work flawlessly. So while the reasonable course of action is to use MBS in order to obtain a perfect result, I feel that a collective study of the date difference calculus is worth, if only for intellectual interest.
In keeping with the topic of the OP, I will suggest that Hamish Steiner’s code is a good start, except it does not take into account the leap years. Which can easily be fixed with the short method I posted above. He feels there ought to be a more elegant way. Maybe what he has done so far is already very good, but just needs refinement to take into account edge cases.
May we all continue working on the coding, instead of needlessly verse in petty quarrels ? Hamish longed for elegance in code. I long for elegance in conversation.
I apologize for posting such buggy code. Here is a tested, working version.
dim d1 as new date(2013, 2, 20)
dim d2 as new date(2014, 2, 5)
dim d3 as date
dim dyear, dmonth, dday as integer
dyear= d2.year- d1.year
dmonth= d2.month- d1.month
dday= d2.day- d1.day
if dmonth< 0 then
dyear= dyear- 1
dmonth= dmonth+ 12
end
if dday< 0 then
dmonth= dmonth- 1
if dmonth< 0 then
dyear= dyear- 1
dmonth= dmonth+ 12
end
d3= new date(d2)
d3.day= 0
dday= dday+ d3.day
end
This problem is at first blush deceptively simple. It’s the edge cases that kill you. It has the same pitfalls as calculating someone’s age or coding a binary search. They’re very easy, but hard to get just right. Even the best programmers have to take a couple of tries to catch the edge cases.
[quote=126476:@Michel Bujardet]It should be possible to solve ;
The only variable length month is February, because of the leap year. Xojo calculates very well the number of days in February.
[/quote]
Sure.
But my pint is there’s still edge cases that “common usage” doesn’t give decent heuristics for.
Start on Mar 29 of ANY year.
Subtract “one month” - what date do YOU get ?
Some will say a date at the end of february - even the last day of feb because thats month 3 less 1 month = some day in month 2
but since that month has fewer days you pick the last day of the month.
But not always - others may say you should be on a date in January (more literally one month = 30 days)
Counting in days is reasonably precise.
Counting in weeks is also.
Counting in any other units requires some heuristics - and then you get into situations where “well I would have said” vs what someone else would have said.
