How many Years Months and Days ?

[ggauny@live.fr]

Hi,
Sometime ago I'd post a routine for Prime to calculate DYMD between 2 dates.
Since I've HP 35s (pure RPN) I've retrieve a routine from 1980 ! that do the same thing, but very more "elegant" :

Lbl YMD 365.2564 / FIX1 INT LASTx FRC 365.2564 * 30.44 / INT LASTx FRC 30.44
* FIX0.
Enter the number days between 2 dates, XEQ YMD.
YEARS are in Z, MONTHS in Y, and DAYS in X.

Ex: 23389 (days) XEQ YMD -----> 64y 0m 13d.

Very possible to enhance the output and port on any machine.

Good night.

Gérard.

[Dieter]

(03-08-2015 06:57 PM)ggauny@live.fr Wrote:  Lbl YMD 365.2564 / FIX1 INT LASTx FRC 365.2564 * 30.44 / INT LASTx FRC 30.44
* FIX0.
Enter the number days between 2 dates, XEQ YMD.
YEARS are in Z, MONTHS in Y, and DAYS in X.

Ex: 23389 (days) XEQ YMD -----> 64y 0m 13d.

Ah, very interesting. May I ask a few questions?

1. Let's try some sample cases:
   Example A: Add 23389 days to 1 Jan 1900 and you'll get 15 Jan 1964. That's 64 years and 14 days.
   Example B: Add 23389 days to 1 Mar 1900 and you'll get 14 Mar 1964. That's 64 years and 13 days.
   Example C: the program translates 365 days into 0 years, 11 months and 30(,16) days.
   That's why I think you cannot consistently translate a given number of days into years, months and days.
2. The program multiplies by 365,2564 and then divides by 30,44. This is equivalent to a multiplication by 11,9992. Is this supposed to be 12? The formula sounds interesting, but is there any proof?
3. The program first sets FIX 1 and finally FIX 0. What's the purpose of this? If the last result (number of days) should be rounded to the next integer, you can simply add a final 0,5 [+] [INT].
   

Dieter

[ggauny@live.fr]

Hallo Dieter,

You are rigth, the acuracy is not exhaustive in this routine, even the solar sidéral
year is a good base. Acuracy more or less one day. I've done a "sloppy job" as said Namir. I'm going to enhance.

Thanks a lot for remarcs.

Nice day
Gérard.

[Dieter]

(03-08-2015 06:57 PM)ggauny@live.fr Wrote:  Very possible to enhance the output and port on any machine.

You said you also want to try the 34s, so here is a first idea on how to do it using the built-in date functions.
Caution: this code is completely untested, I finished it just five minutes ago. Any error you can imagine is possible. ;-)

Code:

LBL'YMD'
STO 02
DAY
x<>y
STO 01
DAY
x≤y?
GTO 01
#012
RCL 02
YEAR
RCL 02
MONTH
DEC X
x=0?
DEC Y
x=0?
x<>Z
RCL T
GTO 02
LBL 01
RCL 02
YEAR
RCL 02
MONTH
RCL Z
LBL 02
→DATE
RCL 01
RCL Y
ΔDAYS
#012
x
#a
/
ROUNDI
RCL X
#012
IDIV
x<>Y
#012
RMDR
RCL Z
RCL 02
ΔDAYS
RTN

Enter date1 [ENTER] date2 using the currently set date format, where date1 is the earlier date resp. date2 the later one. The number of years, months and days is returned on the stack (Z, Y and X).

Example (assuming d.my mode):

Code:

  14,071979 [ENTER] 4,052011

     XEQ'YMD'

     Z = 31
=>   Y =  9
     X = 20

i.e. 31 years, 9 months and 20 days.

If you prefer the result in one single value, simply add these lines before the final RTN:

Code:

SDR 002
+
SDR 002
+
FIX 04

This way the example would return 31,0920.

As usual, comments and corrections are welcome.

Dieter

Edit: Sorry, I just realized this is the 41C software library. ;-)

[ggauny@live.fr]

Hi,

You are really very fine, i very learn with you. I think you are teacher in maths or ingenior in informatic. Thanks for the codes, but not yet the WP 34s, damned !
I remember in school the "chronological substraction" about same for hours, minutes and seconds.
-1 +30
-1 +12
EX : 23 02 1951---> 1950 01 23
30 06 1950---> 1949 05 30
----------------
0 7 23

We put only really finished years and months, days are days. If it is impossible to substract, i take on unity on the left and add in the new unity : - 1 year = +12 months, -1 month=30 days. Always 30days, never 28,29or 31, always 30 days.

The chronologiqual substraction is the best and shorter to calculate Delta Y M D.

No matter with leaps or not leaps etc.

May i have your in head felling of this. In some calendars calculations i use this
to be sure of no error.

Your Trully
Gérard

[ggauny@live.fr]

Hi,

You are really very fine, i very learn with you. I think you are teacher in maths or ingenior in informatic. Thanks for the codes, but not yet the WP 34s, damned !
I remember in school the "chronological substraction" about same for hours, minutes and seconds.
-1 +30
-1 +12
EX : 23 02 1951---> 1950 01 23
30 06 1950---> 1949 05 30
----------------
0 7 23

We put only really finished years and months, days are days. If it is impossible to substract, i take on unity on the left and add in the new unity : - 1 year = +12 months, -1 month=30 days. Always 30days, never 28,29or 31, always 30 days.

The chronologiqual substraction is the best and shorter to calculate Delta Y M D.

No matter with leaps or not leaps etc.

May i have your in head felling of this. In some calendars calculations i use this
to be sure of no error.

Your Trully
Gérard

[Dieter]

(03-11-2015 08:46 AM)ggauny@live.fr Wrote:  You are really very fine, i very learn with you. I think you are teacher in maths or ingenior in informatic.

Far, far away from that. #-)

(03-11-2015 08:46 AM)ggauny@live.fr Wrote:  I remember in school the "chronological substraction" about same for hours, minutes and seconds.
...
We put only really finished years and months, days are days. If it is impossible to substract, i take on unity on the left and add in the new unity : - 1 year = +12 months, -1 month=30 days. Always 30days, never 28,29or 31, always 30 days.

If I understand this correctly, the method works as follows:

Code:

Let d1, m1, y1 (d2, m2, y2) represent the earlier (later) date.

Δd = d2-d1
if Δd<0 then
   Δd = Δd+30
   m2 = m2-1
Δm = m2-m1
if Δm<0 then
   Δm = Δm+12
   y2 = y2-1
Δy = y2-y1

On the HP41 series (and most other classic RPN HPs) this can be implemented easily.
The following code assumes two dates are entered in X and Y (earlier ENTER later) in dd.mmyyyy format.

Code:

01 LBL"YMD"
02 STO 02
03 INT
04 ST- 02
05 x<>y
06 STO 01
07 INT
08 ST- 01
09 -
10 100
11 ST* 01
12 ST* 02
13 RDN
14 x≠0?
15 x>0?
16 GTO 00
17 30
18 +
19 1
20 ST- 02
21 RDN
22 LBL 00
23 RCL 02
24 INT
25 ST- 02
26 RCL 01
27 INT
28 ST- 01
29 -
30 1E4
31 ST* 01
32 ST* 02
33 RDN
34 x≠0?
35 x>0?
36 GTO 00
37 12
38 +
39 1
40 ST- 02
41 RDN
42 LBL 00
43 RCL 02
44 RCL 01
45 -
46 END

72 Bytes

The result is returned in X (Δyears), Y (Δmonths) and Z (Δdays).

If you're not familiar with the tricks and tweaks of the olden days: the two consecutive tests (x≠0? x>0?) behave like a x≥0? test (which the '41 does not offer).

(03-11-2015 08:46 AM)ggauny@live.fr Wrote:  The chronologiqual substraction is the best and shorter to calculate Delta Y M D. No matter with leaps or not leaps etc.

It's a fast and concise method. Whether it's "the best" or not may be discussed – it's not quite exact. But not less so than the 30/360 method of the financial guys. ;-)

Dieter

[ggauny@live.fr]

HI,

Once again thank you for the program. I have programed this routine there is a long time ago but i adopt you because you program better than i.

My old routine was running well but i did not know the trick for tests on x and 0, so it was longer.

"Gut Nacht und auf Wiedersehen"

Gérard

[Dieter]

(03-11-2015 06:02 PM)ggauny@live.fr Wrote:  My old routine was running well but i did not know the trick for tests on x and 0, so it was longer.

The main advantage of this method is its elegance and simplicity, especially when the test is not followed by a GTO. In this case however it saves just one single step:

Code:

standard   improved
-------------------
 x=0?       x≠0?
 GTO 00     x>0?
 x>0?       GTO 00
 GTO 00

I also have been thinking about the simplified date calculation you suggested. The basic conclusion is: there is no definitive answer in terms of years, months and days because it all depends on how you look at it.

Let's try an example: 25.02.1950 and 23.06.1951.

You may say that it's 1 year and 3 months from 25.02.1950 to 25.05.1951, and then another 29 days from 25.05. to 23.06.1951.
So the result is 1 year, 3 months and 29 days.

But you may just as well say that between 25.02. and 23.03.1950 there are 26 days, and from there it's exactly 1 year and 3 months until 23.06.1951.
So the result is 1 year, 3 months and 26 days.

Now, if the result depends on the way you look at the problem, one day more or less doesn't matter much either.
BTW the simplified method with 30 days per month returns 1 year, 3 months and 28 days. ;-)

Dieter

[ggauny@live.fr]

Holle Dieter,

I agree with you, one more or less it is not really important in the current live.
But i have poste a program for Prime named DAMJ witch give 1Y 3M and 26D.

May be it exist a program that is really exact but i don't. You surely you know...

Cheers
Gérard

[ggauny@live.fr]

HI,
Here is the program i was speaking.

See you soon

Gérard

[Dieter]

(03-13-2015 10:48 AM)ggauny@live.fr Wrote:  I agree with you, one more or less it is not really important in the current live.
But i have poste a program for Prime named DAMJ witch give 1Y 3M and 26D.

Yes, I remember.

(03-13-2015 10:48 AM)ggauny@live.fr Wrote:  May be it exist a program that is really exact but i don't. You surely you know...

Maybe I was not clear enough in my previous post. The essential point here is: there is not just one single "exact" solution. There are at least two possible ways to look at the problem, and at least two solutions can be considered exact. Take a look at the example in my last post. Both 29 and 26 days are equally correct answers. The first method accounts for the number of days in May (=31), the second solution is based on the number of days in February (=28). That's why the results differ by three days. But both results are equally correct.

Your simplified method uses 30 days for every month, so it returns 28 days. There also is a similar function in Excel (DATEDIF). That one is based on 31 days for every month, so it returns 29 days here. Which again proves that Excel really is no reference in terms of mathematics. ;-)

Dieter

[Dieter]

(03-13-2015 07:40 PM)ggauny@live.fr Wrote:  Here is the program i was speaking.

This one uses the second method in my previous post. The result depends on the number of days in the month of the earlier date (here February). Which is L(b) in your program.

You can also try the other method that is based on the number of days in the month preceding the one in the later date. In the example this would be May (the month before June). This approach can be implemented by replacing L(b) with L(e–1). Of course you have to make sure that e–1=0 is handled correctly. L(0) actually is L(12) = 31, the number of days in December.

Dieter

[ggauny@live.fr]

Hallo Dieter,

I retrieve on my HP 50g a program named DYMD. May be you have, it is on HP48.org. But impossible to see the algorithm, it is a library written with "JAZZ", it seem more acurate then mine.

Have a good sunday.
Gérard

[ggauny@live.fr]

Did you know this site ? If no i send you attachement zip, i have little little bit participated.

[ggauny@live.fr]

I've forget to put you an exemple : 18/06/1582, i beg you for this.

[Dieter]

(03-15-2015 12:36 PM)ggauny@live.fr Wrote:  I've forget to put you an exemple : 18/06/1582, i beg you for this.

Thank you very much – the Excel file is really quite impressive.

It even handles the transition from Julian to Gregorian calendar in 1582 correctly. At least if the according parameters are adjusted to 4/15 October. ;-) Before that the switch date was set to 9/20 December 1582, which seems to be the correct date for France.

Dieter

[ggauny@live.fr]

Yes this Excel calculation is for France because i am french. It easy to put your switch for Germany at 18/02/1700. (Thank's to Marcus von Cube editing dates of switches).

[Paul Dale]

The 34S folks had a long discussion about the appropriate date of change over.
We ended up supporting two different ones.
We couldn't do more due to memory constraints.


- Pauli

[Paul Dale]

(03-16-2015 08:40 AM)ggauny@live.fr Wrote:  Yes this Excel calculation is for France because i am french. It easy to put your switch for Germany at 18/02/1700. (Thank's to Marcus von Cube editing dates of switches).

Interesting that Australia changed to the Gregorian calendar in 1752. It wasn't settled by Europeans until 1788 and it was not discovered by the English until 1770 by Captain James Cook on the Endeavour!


- Pauli