Year(s) Month(s) Day(s) between 2 dates

[Didier Lachieze]

Gérard has brought me an interesting question: with a start date of 23 Feb. 1951 and an end date of 5 Sept. 1999 the program from Dieter with ΔDAYS (as well as my optimized versions) returns 48 years, 6 months and 13 days, however Gerard’s own program as well as another one he has on the 50g (not written by him) returns 48 years, 6 months and 10 days.

The difference in the number of days comes from the way the interval duration is calculated:
If you add 48 years and 6 months to the start date you get 23 Aug. 1999, 13 days before 5 Sept. 1999.
However if you first add 10 days to the start date you get 5 mar. 1951 which is 48 years and 6 months before 5 Sept. 1999.

So we have two different numbers of days because the “6 months” are not the same months: in the first case the 28-day February is included in the 6 months* but not in the second case where it’s replaced by the 31-day August**, hence the 3 days difference.

As the answer depends on the order of operations maybe this should be reflected in the result: '48 years, 6 months and 13 days' or '10 days, 6 months and 48 years'.

I’ve checked a few on-line date interval calculators and I’ve got the two answers.

48 years, 6 months and 13 days:

• WolframAlpha
• timeanddate.com
  

48 years, 6 months and 10 days:

• Date Interval Calculator
  

Does anybody knows if there is a standard rule for calculating such date intervals and if one of the two possible answers should be considered the right one?

*we add first the 48 years to get to 23 Feb. 1999, then we add the 28 days of Feb to 23 Mar. 1999, then the 31 days of Mar. to 23 Apr. 1999 .... and the 31 days of July to 23 Aug. 1999 and then 13 days to 5 Sept. 1999. So the 6 months are: Feb. Mar. Apr. May Jun. Jul.

**after adding 10 days to 23 Feb. 1951 we get to 5 Mar. 1951, then we add the 31 days of Marc. to 5 Apr. 1951 .... then the 31 days of Aug. to 5 Sept. 1951 and then the 48 years to 5 Sept. 1999. So the 6 months are: Mar. Apr. May Jun. Jul. Aug.

[ggauny@live.fr]

Hi,

I'm going be clear. In my algorithm think like as follow :

First : numbers of days : in feb 1951 are 28 days (year not leap). I count then 28-23 = 5 days.
In sep 1999 are 5 days (in our example).

For me I have 10 days.

Second : numbers of full months : sep is out of course so second date has 8 months full, then 8 months - 2(feb month) give 6 months.

Third : 1999 - 1951 give 48

So 48 years 6 months 10 days.


The other possible calculation is the "chronological substraction" like this :


-1
1998 8 5
1950 1 23

=48 =6 -18
+31 (number of days in month number 8 aug)
= 13

We have to count only years AND month full, eg as 1999 is not finish we write 1998, as month 9 is not finish we write 8 and so on. Only the days are of course finished.


Personaly I prefer 48 years 6 months AND 10 days, because "5+5=13" hurt me.

It is difficult to explain clearly in english, and I beg your pardon.

Gérard.

[ggauny@live.fr]

Dear Sir,

May I thank you for your post, it is exactely what I think but impossible for me to explain in english.

I see that you have understood what I mean. Of course the difficulty is in the mode of raisonning, I say again that I prefer my solution, not only because it is my solution, but also because my solution for me is more logic for dayli calculations.

Mimo to, I thank you for your help.

Gérard.

[Dieter]

(10-23-2015 03:42 PM)Didier Lachieze Wrote:  Gérard has brought me an interesting question: with a start date of 23 Feb. 1951 and an end date of 5 Sept. 1999 the program from Dieter with ΔDAYS (as well as my optimized versions) returns 48 years, 6 months and 13 days, however Gerard’s own program as well as another one he has on the 50g (not written by him) returns 48 years, 6 months and 10 days.

The difference in the number of days comes from the way the interval duration is calculated:
If you add 48 years and 6 months to the start date you get 23 Aug. 1999, 13 days before 5 Sept. 1999.
However if you first add 10 days to the start date you get 5 mar. 1951 which is 48 years and 6 months before 5 Sept. 1999.

Yes – this point has already been discussed in March in the original thread on this topic (see also post #12). There simply is no unique "correct" answer in years, months and days because the result depends on the way you do the calculation.

(10-23-2015 03:42 PM)Didier Lachieze Wrote:  Does anybody knows if there is a standard rule for calculating such date intervals and if one of the two possible answers should be considered the right one?

I think we can safely assume that "the standard" is Wolfram Alpha. ;-)

Dieter

[Dieter]

(10-23-2015 04:38 PM)ggauny@live.fr Wrote:  Personaly I prefer 48 years 6 months AND 10 days, because "5+5=13" hurt me.

Whether the first value is 5 (days in February) or 8 (days in August) is something that can be discussed. ;-)

But if it really hurts so much you can adjust the program without major effort. Currently the number of days is calculated as the difference between 23 Aug 1999 and 5 Sep 1999, which is 13 days, obtained via the ΔDAYS function. If you prefer the other approach, all you need is the difference between 23 Feb 1951 and 5 Mar 1951, which is 10 days. In my original program this is the part between line 12 and 24.

Dieter

[fhub]

Hi,

I've now entered both programs from Dieter and Didier (each in the last updated version), and there must be something wrong with the listings, because both programs don't work correctly!

Look at the results for the 3 dates that have been mentioned in this thread:

Code:


18.071978 to 19.102015 --> 36.1431 instead of 37.0301
14.051643 to 01.091715 --> 71.1518 instead of 72.0318
23.021951 to 05.091999 --> 47.1813 instead of 48.0613

Not even the most simple dates work, where every number in date2 is higher than in date1, although in this case you could even just subtract the 2 dates:

Quote:03.052000 to 10.102015 --> 14.1637 (16 months?, 37 days?)

And for some special dates the results are complete nonsense:

Quote:01.012000 to 01.022000 --> -0.87
31.012015 to 01.032015 --> Domain Error
31.012015 to 01.042015 --> -0.8599

And now about the problem of 2 different results for Didier's example (23 Feb. 1951 to 5 Sept. 1999):
I definitely agree with Gérard that the 'correct' result is 48y/6m/10d and NOT 48y/6m/13d!

You can't move forward to 23 Aug 1999, at least NOT for all cases - try your method with the following 2 dates (in any year YYYY):
31 Jan. YYYY to 5 March YYYY
You can't move forward to 31 Feb., because Feb. simply doesn't have 31 days!
(same problem with 30 or 29 Jan, or if the 2nd month is May/July/Oct/Dec)

So in fact Gérard's method is correct, unless you want to make a lot of differences between all kinds of months.

In short words: (for d1.m1yyy1 to d2.m2yyy2)
If d2<d1, then you have to add the remaining days in m1 and the days d2, and change the first date to the 1st day of the following month.

Here's my own (really working! ) version, which uses exactly the method I've described above - you only must take care that the result is also in the same format DD.MMYYYY as the the input dates (therefore the name DMY)!
I've made it this way, because
1) IMO it's more consistent if the input and output have the same format, and
2) everything can be done on the 4-level stack (no extra registers needed), so
3) the program is much smaller (only 29 steps!)

Quote:0001 LBL'DMY'
0002 [<->] YXYX
0003 [cmplx]IP
0004 x[<=]? Y
0005 SKIP 011
0006 [<->] ZZTT
0007 FP
0008 INC X
0009 # 031
0010 DAYS+
0011 FP
0012 INC X
0013 STO Z
0014 [DELTA]DAYS
0015 STO+ Z
0016 ENTER[^]
0017 [<->] ZTZT
0018 [cmplx]FP
0019 x[<=]? Y
0020 SKIP 006
0021 DROP
0022 # 012
0023 SDL 004
0024 DEC X
0025 SDR 006
0026 STO+ T
0027 [cmplx]DROP
0028 -
0029 END

Franz

[Dieter]

(10-27-2015 03:06 PM)fhub Wrote:  I've now entered both programs from Dieter and Didier (each in the last updated version), and there must be something wrong with the listings, because both programs don't work correctly!

I deleted the program in my 34s and re-entered it according to the listing I provided. Then I tried your examples:

(10-27-2015 03:06 PM)fhub Wrote:  Look at the results for the 3 dates that have been mentioned in this thread:
18.071978 to 19.102015 --> 36.1431 instead of 37.0301
14.051643 to 01.091715 --> 71.1518 instead of 72.0318
23.021951 to 05.091999 --> 47.1813 instead of 48.0613

Not even the most simple dates work, where every number in date2 is higher than in date1, although in this case you could even just subtract the 2 dates:
03.052000 to 10.102015 --> 14.1637 (16 months?, 37 days?)

I tried all the above cases, and my program returned all results correctly: 37.0301, 72.0318 and 48.0613. And the last case did not return 14.1637 but 15.0507.

So the error must be on your side. You probably entered the program incorrectly.

(10-27-2015 03:06 PM)fhub Wrote:  And for some special dates the results are complete nonsense:
01.012000 to 01.022000 --> -0.87
31.012015 to 01.032015 --> Domain Error
31.012015 to 01.042015 --> -0.8599

My program correctly returns 0.0100 for the first case and 0.0201 for the third. The weird answers you got must be caused by an error on your side.

The second case indeed throws a Domain Error since the program tried to calculate the difference between 31 February (!) and 1 March 2015. This should get fixed. Also changing the code to the alternative method you prefer is quite simple.

But again, please check the code in your 34s. You must have entered something wrong.

Dieter

[fhub]

(10-27-2015 11:25 PM)Dieter Wrote:  So the error must be on your side. You probably entered the program incorrectly.

Well, I've already checked it 3 times before, and now I've even created a disassembler listing from my entered program and checked it again - I can't find any differences!
Look by yourself - here's the listing which you can compare with your posted listing:

Code:


001 LBL'YMD'
002 STO 02
003 DAY
004 x[<->] Y
005 STO 01
006 DAY
007 -
008 CF 00
009 x=0?
010 GTO 01
011 SF 00
012 RCL 02
013 DATE[->]
014 DROP
015 DSZ X
016 SKIP 003
017 DROP
018 # 012
019 DEC Y
020 RCL 01
021 DAY
022 [->]DATE
023 RCL 02
024 [DELTA]DAYS
025 LBL 01
026 SDR 004
027 RCL 02
028 MONTH
029 FS?C 00
030 DEC X
031 RCL 01
032 MONTH
033 -
034 x=0?
035 SKIP 003
036 SF 00
037 # 012
038 +
039 SDR 002
040 +
041 RCL 02
042 YEAR
043 FS?C 00
044 DEC X
045 RCL 01
046 YEAR
047 -
048 +
049 END

I've no idea what could be the reason for our different results - I'm running this program on the standard WP34s emulator with default settings.

Franz

[Didier Lachieze]

Franz, steps 9 and 34 should be X[>=]0? not X=0?

[fhub]

(10-28-2015 01:57 AM)Didier Lachieze Wrote:  Franz, steps 9 and 34 should be X[>=]0? not X=0?

Ahhh, now everything is clear - many thanks Didier!

The problem was that I just did a copy&paste of the listings to a text file, and this changed the non-ASCII character ≥ to =, so this line in _my_ text looked like this:
09 x=0? ; d2 = d1?

Since I've always (4-times!) compared my entered program with this text file (and not directly with the listing here), of course I couldn't find any difference.

PS: there's still the problem in your programs when the 1st day is e.g. 30 or 31, and the 2nd month is 3, 5, 7, 10 or 12 (with d2<d1) - examples:
from 30.012015 to 5.032018 --> Domain Error
or
from 31.012015 to 5.072018 --> Domain Error
etc.

Thanks again,
Franz

[Dieter]

(10-28-2015 12:24 AM)fhub Wrote:  I've no idea what could be the reason for our different results - I'm running this program on the standard WP34s emulator with default settings.

Code:

034 x=0?

Found in ten seconds even without comparing with the original code.

(10-28-2015 12:24 AM)fhub Wrote:  PS: there's still the problem in your programs when the 1st day is e.g. 30 or 31, and the 2nd month is 3, 5, 7, 10 or 12 (with d2<d1)

Right. This can be fixed.

Dieter

[fhub]

(10-28-2015 11:48 AM)Dieter Wrote:  

Code:

034 x=0?

Found in ten seconds even without comparing with the original code.

Well, this 'original' code is your code, so of course you see this immediately.
But you don't really expect me to check each single line of your code, when I just copy&paste a listing, do you?
(analyzing a program from someone else would be 10-times more work than writing the program myself)

Franz

[Didier Lachieze]

(10-27-2015 11:25 PM)Dieter Wrote:  The second case indeed throws a Domain Error since the program tried to calculate the difference between 31 February (!) and 1 March 2015. This should get fixed. Also changing the code to the alternative method you prefer is quite simple.

Here is an updated version with a fix for the Domain Error at the expense of 3 additional steps for a total of 40 steps:

Code:

01 LBL"YMD"   ; stack: date2, date1
02 LocR 004   ; allocate local registers R.00 to R.03
03 cSTO.00    ; store date2 in R.00 and date1 in R.01
04 DATE->     ; stack: d2, m2, y2, date1
05 <>YZTX     ; stack: m2, y2, date1, d2
06 cSTO.02    ; store m2 in R.02 and y2 in R.03
07 cX<>Z      ; stack: date1, d2, m2, y2
08 DAY        ; stack: d1, d2, m2, y2
09  -         ; stack: d2-d1, m2, y2 – LastX: d1
10 x≥0?       ; d2 ≥ d1?
11 SKIP 014   ; no adjustment required, goto step 26
12 DEC.02     ; adjust m2 in R.02
13 DROP       ; stack: m2, y2 – LastX: d1
14 Z<> L      ; stack: m2, y2, d1 
15 #01        ; stack: 1, m2, y2, d1 
16 ->DATE     ; 1st day of month m2 in year y2
17 #01
18 +/-
19 DAYS+      ; 
20 DATE->     ; stack: last day of month m2-1, m2-1, y2(-1), d1
21 RCL T      ; 
22 MIN        ; min(d1, last day of m2-1)
23 ->DATE     ; generate new date = d1 in month before m2
24 RCL.00
25 ΔDAYS      ; days between date2 and d1 in month before date2
26 SDR 004    ; move days to 0,00dd
27 RCL.01     ; recall date1
28 DATE->     ; stack: d1, m1, y1, 0,00dd
29 DROP       ; stack: m1, y1, 0,00dd
30 cSTO-.02   ; R.02: m2-m1, R.03: y2-y1
31 cX<>.02    ; stack: m2-m1, y2-y1, 0,00dd
32 x≥0?       ; stack: m2-m1, y2-y1, 0,00dd
33 SKIP 003
34 DEC Y      ; adjust y2-y1 if m2-m1 negative
35 #012       ; add back 12 months
36  +         ; stack: mm, y2-y1, 0,00dd 
37 SDR 002    ; move months to 0,mm
38  +         ; add y2-y1  to get y,mm 
39  +         ; add days to get y,mmdd
40 END        ; return y,mmdd

Compared to Franz version in 29 steps, this one is independent of the input date format as long as it is consistent with the WP 34S current Mode (output format is always YMD), and the results are aligned with WolframAlpha:

in D.MY format:
18.071978 to 19.102015 --> 37.0301
14.051643 to 01.091715 --> 72.0318
23.021951 to 05.091999 --> 48.0613
01.012000 to 01.022000 --> 0.01
31.012015 to 01.032015 --> 0.0101
31.012015 to 01.042015 --> 0.0201

in M.DY format:
07.181978 to 10.192015 --> 37.0301
01.312015 to 03.012015 --> 0.0101

[fhub]

(10-28-2015 12:11 PM)Didier Lachieze Wrote:  ..., and the results are aligned with WolframAlpha:

Yes, your new version behaves in fact exactly like WolframAlpha - look at the following 2 examples:
30.012015 to 29.032015 --> 1 month 29 days
31.012015 to 29.032015 --> 1 month 29 days

Ooops, 2 different start days give the same result?
So for WolframAlpha (and for you) 30.Jan and 31.Jan are the same day?
(and there's no 30. or 31. Feb to which you could move forward from the Jan. start day)

Doesn't seem very logical to me, not even if WolframAlpha states it.

Added:
For end date 28.March it's even worse:
29.012015 to 28.032015 --> 1 month 28 days
30.012015 to 28.032015 --> 1 month 28 days
31.012015 to 28.032015 --> 1 month 28 days
Three different start dates, but all give the same result!

Franz

[Didier Lachieze]

(10-28-2015 03:24 PM)fhub Wrote:  

(10-28-2015 12:11 PM)Didier Lachieze Wrote:  ..., and the results are aligned with WolframAlpha:

Yes, your new version behaves in fact exactly like WolframAlpha - look at the following 2 examples:
30.012015 to 29.032015 --> 1 month 29 days
31.012015 to 29.032015 --> 1 month 29 days

Ooops, 2 different start days give the same result?
So for WolframAlpha (and for you) 30.Jan and 31.Jan are the same day?
(and there's no 30. or 31. Feb to which you could move forward from the Jan. start day)

Doesn't seem very logical to me, not even if WolframAlpha states it.

Yes, it’s far from perfect. But the problem in calculating date intervals here is that we are dealing with a variable unit (a month can be 28, 29, 30 or 31 days long), so troubles occur at the boundaries.

With your program there are also some discontinuities:
25.012015 to 28.022015 --> 1 month 3 days
25.012015 to 01.032015 --> 1 month 7 days (+4 days!)

Adding one day to the end date increases the result by 4 days! 3 “phantom” days have been added between the 28 of February 2015 and the 1st of March 2015.

And this depends also on the start month:
25.112014 to 28.022015 --> 3 month 3 days
25.112014 to 01.032015 --> 3 month 6 days (+3 days!)

Here only 2 “phantom” days have been added between the 28 of February 2015 and the 1st of March 2015.

All this is not very consistent and without a clear and agreed standard way of calculating date intervals the results are quite useless from my point of view.

[ggauny@live.fr]

Hi,

Difference is only for days, of course ! I'm triying to exploite a test to know if between start date and end date Is Feb. month. So, according leap or not, on paper the error must diseapear no ?

I try to test this "solution" in my old Pgm, because I know it.

Gérard.

[ggauny@live.fr]

Hi again,

Want you reason this :

I ask my machine to see if the m1 = 1, so if days are negative don't add 31 but only 28 or 29.

It is like' this we do by hand on paper, of course it seems difficult to implement in my pgm.

Gérard.

[fhub]

(10-29-2015 07:52 AM)Didier Lachieze Wrote:  With your program there are also some discontinuities:
25.012015 to 28.022015 --> 1 month 3 days
25.012015 to 01.032015 --> 1 month 7 days (+4 days!)

That's a very bad example and can in no way be compared to the illogical examples that I've mentioned above:
In your example there's a change in the month of the end date, and so of course there's a 'discontinuity' (I'm sure you also know other discontinuous math functions, don't you?) - I never stated that this DMY function should be continuous.

The last example that I have given shows that with WolframAlpha's method even 3 consecutive (i.e different) dates in the same month give the same result for one single end date, and that's simply nonsense, point!

Franz

[ggauny@live.fr]

I agree, I'd send you this.
It helps me to compute formulaes calendarium, may be you have already.
You have to ok in options for macro.