Deltadays and date functions.

[Dieter]

(05-10-2017 07:16 PM)Vtile Wrote:  But isn't 2100 a regular year as it is divisable with 100 and 4, but not 400. I must be mixing up something now.

Leap years are those that can be divided by 4, but not by 100, and then also those that are divisible by 400. So no, 2100 is not a leap year. That's why the simple program version works until 28 Feb 2100 but not beyond. Remember, regular and leap years only differ after Feb 28 where the next day may be Feb 29 or 1 Mar. ;-)

(05-10-2017 07:16 PM)Vtile Wrote:  (Assuming the RPN program you kindly provided doesn't take somehow account the "regular year if divisable with 100" rule. My RPN still needs to some practice to fluently read it.)

The first, simplified program version does not care about the divisible-by-100 rule at all. It simply assumes that every 4th year is a leap year. Which is true for the given date range as it starts not before Mar 1900 and it ends in Feb 2100. The special case 2000 is divisible by 400 and so it is a leap year, like any other in the given date range that is divisible by 4. That's why the simplified formula works for a 200-year-interval instead of just a century.

(05-10-2017 07:16 PM)Vtile Wrote:  This were suprising, while I did know that it do have quirks in number handling etc. (which I learned from here) I would have assumed it have state of the art calendar functions for accounting and so forth reasons.

You should see what Excel does with some higher-level math functions, or with statistical distributions... #-)

(05-10-2017 07:16 PM)Vtile Wrote:  Yes, now I see the function of the 0,25 (1/4) as it is calculated to days with INT/FLOOR only each four years, so it makes the leap year handling in this narrow implementation.

Yes.

(05-10-2017 07:16 PM)Vtile Wrote:  On the other hand I still not get it how the months are handled so sophisticated that the sequence 31,28(**),31,30,31,30,31,31,30,31,30,31 (2+5+5) drops in to that 0.6 with the month shifting IF M<3 THEN M=M+12 and Y=Y-1.. *scratching his head*

That's not too hard to understand. Remember that a year starts with March (M=3) and ends with next year's February (M=14). So leap year or not is not a question here: the first day is 1 March, and at the end of the year at most 28 or 29 days are added.

Now write down INT(30,6*(M+1)) and compare this with the number of days accumulated in a year. The INT expression is just the number of elapsed days since 1 March, plus 122. The latter does not matter here. Subtract 122, and for M=14 (Feb) you get 337. Now add 28 days and get 365 days of a regular year.

So the 30,6 is simply a factor that generates the sequence 0, 31, 61, 92... days that elapsed since 1 March.

(05-10-2017 07:16 PM)Vtile Wrote:  Well it is 3/5 so it is also found from the JDN algorithm and also from the algorithm mentioned by Don Shepherd.. Somehow it relates to that divisor 5.

Instead of multiplying by 30,6 you can also multiply by 153/5 which is the preferred solution for most computer languages that use binary number encoding which may result in roundoff errors here: the result of 30,6x5 may be 152,9999... instead of 153 so that INT is off by one. That's why you often find 30,6001 or 30,61 instead of plain 30,6. For BCD calculators like ours this is not required. In most computer programming languages the preferred solution is evaluating 153*(m+1) which is an integer, and then do an integer division (DIV) by 5. The same idea applies to 365,25*Y resp. (1461*Y) DIV 4.

(05-10-2017 07:16 PM)Vtile Wrote:  Do you mind if put a link to this program in my (X)IRR/(X)NPV topic at http://www.hpmuseum.org/forum/thread-8322.html.

No problem. But I think you should link to the second improved version, the one without the limitations of the original simplified one. If you want a more sophisticated calendar program you may want to take a look at this one.

And finally, here is another one that uses a different approach for date differences. ;-)

Dieter