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.

(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?

- 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.
- 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?
- 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

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.

(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. ;-)

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

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

(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

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

(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

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

HI,

Here is the program i was speaking.

See you soon

Gérard

(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

(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

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

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

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

(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

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).

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

(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