WP34s: date functions and negative years

[Dieter]

While playing around with some calendar and date algorithms I discovered an unexpected behaviour of some related functions on the 34s. There seems to be an issue, or at least an inconsistency, with some of its date commands. While everything looks fine for dates down to 1 Jan 0000, earlier (i.e. negative) dates are handled as if they were positive.

Example (assuming d.my mode):

Code:

 18.032002   D->J  2452352
-18.032002   D->J  2452352
             J->D  18.032002

On the other hand, negative (i.e. BC) dates seem fine for the 34s if this is a returned result:

Code:

  989904     J->D -18.032002  Monday  // date correct, but wrong day of week

The returned date (18 Mar 2003 B.C.) is fine, but the displayed day of week is not (should be Sunday). Maybe a final call of the WDAY routine converts the negative date back to positive: 18 March 2002 indeed was a Monday.

The affected functions seem to be D–>J, J–>D, DAYS+, ΔDAYS, DATE–> and maybe others. In all these cases a negative year is changed to positive. Maybe (!) the underlying problem is in the DATE-> function that splits a date into day, month and year. This function generally seems to return a positive year to the stack. If DATE–> is called by other date routines, it's obvious that negative years will produce wrong results:

Code:

-2002 ENTER 3 ENTER 18  ->DATE   -18.032002  Monday   // correct negative date, but wrong day of week (cf. previous J->D example)
 DATE->     X:18    Y:3    Z:2002    // year now is positive
 ->DATE     18.032002

According to the manual the date functions are not limited to positive years. If there was such a limitation I would expect an error message ("Domain error") instead of a wrong result. Otherwise lg —100 should return 2 as well. ;-) However, I think negative input should be allowed since the 34s produces such results as valid output and the common date algorithms work down to 1 January –4712 = JD 0. Only years before –4712 should be rejected. Likewise, negative Julian day numbers should be considered invalid, both as input and output.

Dieter

[Bit]

(01-17-2015 06:39 PM)Dieter Wrote:  ...
While everything looks fine for dates down to 1 Jan 0000, earlier (i.e. negative) dates are handled as if they were positive.
...

Related thread: [WP 34S] Julian day number conversion bug

[Dieter]

(01-17-2015 07:05 PM)Bit Wrote:  Related thread: [WP 34S] Julian day number conversion bug

Ah, thank you - I didn't remember that one. I hope this thread encourages the 34s team to change the weird and inconsistent behaviour I described. IMHO the calculator should either throw an error or return a correct result. The latter of course is the preferred solution. There is no third option - not for a calculator on the level of a 34s. And there is a reason why the JD count starts at JD 0 = 1 January 4713 B.C., so arguing that "no one needs date calculations in this range" is not exactly convincing.

In the old thread Pauli said:

Quote:(...) I could lie about the Julian calendar's reach back in time and ignore the strange stuff

That's not "lying". The correct term is "proleptic". ;-) For B.C. years the Julian calendar simply is assumed to behave the way it did after 8 AD.

Dieter

[Massimo Gnerucci]

(01-17-2015 07:19 PM)Dieter Wrote:  That's not "lying". The correct term is "proleptic". ;-) For B.C. years the Julian calendar simply is assumed to behave the way it did after 8 AD.

Dieter

Proleptic calendar: another thing I learnt today.
Thank you Dieter.

[walter b]

(01-17-2015 07:19 PM)Dieter Wrote:  I hope this thread encourages the 34s team to change the weird and inconsistent behaviour I described. IMHO the calculator should either throw an error or return a correct result. The latter of course is the preferred solution. There is no third option - not for a calculator on the level of a 34s. And there is a reason why the JD count starts at JD 0 = 1 January 4713 B.C., so arguing that "no one needs date calculations in this range" is not exactly convincing.

Oh dear, that 34S project confronts me with problems I didn't even know before

Seriously, JD 0 was defined to cover all recorded human astronomical observations IIRC. OTOH, how shall the poor WP 34S know that an input of -1.012345 (in D.MY or M.DY) shall mean New Year's day of the year 2345 B.C.? There's a reason why ISO defined Y.MD as standard format for dates.

d:-)

[Dieter]

(01-17-2015 09:25 PM)walter b Wrote:  Oh dear, that 34S project confronts me with problems I didn't even know before

That's what this forum is all about.

Quote:Seriously, JD 0 was defined to cover all recorded human astronomical observations IIRC. OTOH, how shall the poor WP 34S know that an input of -1.012345 (in D.MY or M.DY) shall mean New Year's day of the year 2345 B.C.?

Well, it does know this when it returns exactly this result after 864547 D–>J. Even though it returns the wrong day of week. Since days and months are always positive, the sign must belong to the year. That's how the 34s already handles negative dates under certain circumstances.

The 34s, as it is, already returns negative years, so why cannot the user enter the same? Why does the 34s not accept its own (negative) output as valid input for further calculations? And why is the 34s partially wrong? Try 1 Jan 1 BC (a Thursday) and subtract exactly 52 weeks = 364 days: 1.010000 ENTER –364 DAYS+ returns –2.010001 (correct) and "Sunday" (wrong, should be Thursday again).

BTW your example –1.012345 does not refer to 2345 B.C., but 2346 B.C. (the year before 1 AD is 1 BC = year 0).

Quote:There's a reason why ISO defined Y.MD as standard format for dates.

The problems I mentioned occur regardless which date format is set.
And BTW, ISO also defines a proleptic Gregorian (!) calendar. Would you prefer such a solution?

Quote:d:-)

I think the 34s is a serious project and so we should talk about problems seriously. Some of the problems and inconsistencies are listed in my first post. Yes, the device - as it is now - returns results that are simply wrong. Not more, not less. That's why it should be fixed. The one way or the other. Either negative years are rejected with an error message or they have to be handled correctly. Tertium non datur. Do you disagree?

Dieter

[walter b]

(01-17-2015 09:47 PM)Dieter Wrote:  

(01-17-2015 09:25 PM)walter b Wrote:  d:-)

I think the 34s is a serious project and so we should talk about problems seriously. Some of the problems and inconsistencies are listed in my first post. Yes, the device - as it is now - returns results that are simply wrong. Not more, not less. That's why it should be fixed. The one way or the other. Either negative years are rejected with an error message or they have to be handled correctly. Tertium non datur. Do you disagree?

Hey, you're misunderstanding my "signature". I'm not laughing at you. It's just meant to be a friendly sign at the end. You find other posts of me with other "signatures", depending on my respective feelings. Please see below.

d:-/

[Dieter]

(01-17-2015 10:03 PM)walter b Wrote:  Hey, you're misunderstanding my "signature". I'm not laughing at you.

Walter, be assured I did not understand it that way.
But I see serious problems in the 34s date routines that deserve a serious approach for a fix (which I think is mandatory).

Dieter

[Paul Dale]

From memory, there were a number of questions poised on the other thread seeking to determine which of the several wrong possibilities was the most desirable. These questions were not answered, so I didn't implement anything. What we have now is correct as per the documentation -- it is quite explicate that dates before 8AD can be wrong.


We (Walter and I) decided early on to not support dates before the year zero. I thus take the absolution value of inputs in years. I didn't do this for JDNs since they are genuinely useful pre year 0, it is only the conversion to Julian dates that aren't.

• The calendar was bizarre before about 8AD, I could put a break there and force an error.
• The Julian calendar was only introduced late BC, we could break there and live with being incorrect until 8AD, again with an error before.
• We could lie and pretend the Julian calendar went backwards before its creation to the origin of the Julian day number reference.
  

Once we work out which wrong is best, I can fix.


- Pauli

[walter b]

(01-18-2015 01:01 AM)Paul Dale Wrote:  What we have now is correct as per the documentation -- it is quite explicite that dates before 8AD can be wrong.

For sake of completeness, please let me quote footnote 33 of the WP 31S manual:

"Calculation of weekdays for the past depends on the calendars used at that time – there may be different true results for different countries depending on the date the particular country introduced the Gregorian calendar. Officially, that calendar became effective in October 1582 in the catholic world. Many countries switched not earlier than in 1752, others joined even later (until 1949). See the commands JG1582 and JG1752 taking care of most cases. Note, however, there are still also other calendars in use on this planet, e.g. in the Muslim world.
Dates before the year 8 A.D. may be indicated differently than they were at that time due to the inconsistent application of the leap year rule before then. We count on your understanding and hope this shortcoming will not affect too many calculations.
Note that 8 A.D. should be better written A.D. 8 or even A.D. VIII correctly – quite some false Latin is found in the English language. Nobody, however, counted years this way at that time – around the Mediterranean Sea, it was the year DCCLXI A.V.C. then. Also note the Julian calendar was introduced and became valid not earlier than DCCVIII A.V.C. – before, months were organized differently. Julius Caesar was murdered in DCCIX A.V.C., just one year later; calendars may be a sensitive topic."

(01-18-2015 01:01 AM)Paul Dale Wrote:  

1. The calendar was bizarre before about 8AD, I could put a break there and force an error.
2. The Julian calendar was only introduced late BC, we could break there and live with being incorrect until 8AD, again with an error before.
3. We could lie and pretend the Julian calendar went backwards before its creation to the origin of the Julian day number reference.
   

I tend to vote for 1 or 3. 1 would be a clean solution. 3 would allow for calculating weekdays for all recorded events in history of mankind. Though I don't know yet how far back a seven-day week was used and where.

d:-?

[Dieter]

(01-18-2015 08:22 AM)walter b Wrote:  I tend to vote for 1 or 3. 1 would be a clean solution.

Right. If implemented correctly, both ways essentially use the same code with (1) resp. without (3) rejecting years before 8 A.D.

I think the latter decision should be up to the user. There are uses for such a proleptic Julian calendar (that's why it exists):

(01-18-2015 08:22 AM)walter b Wrote:  (...) 3 would allow for calculating weekdays for all recorded events in history of mankind.

It's not because of weekdays (if they had existed the way we use them today), it simply makes date calculations in that era possible.

That's why I vote for solution 3.

Any user is free not to use the date functions for years before 8 A.D. where actually various other calendars were used around the world. Years before –4712 should return an error message since below that point the used formulas (and the resulting negative Julian day numbers) are not defined.

Dieter

[walter b]

Meanwhile, Pauli implemented option 3 but it's not built yet.

d:-)

[Dieter]

(01-19-2015 06:35 AM)walter b Wrote:  Meanwhile, Pauli implemented option 3 but it's not built yet.

Great. And once again thank you to all for their fast reaction.

Dieter

[Paul Dale]

(01-19-2015 06:35 AM)walter b Wrote:  Meanwhile, Pauli implemented option 3 but it's not built yet.

And it isn't heavily tested


Pauli

[Marcus von Cube]

(01-19-2015 07:00 AM)Paul Dale Wrote:  

(01-19-2015 06:35 AM)walter b Wrote:  Meanwhile, Pauli implemented option 3 but it's not built yet.

And it isn't heavily tested


Pauli

and built.

[Dieter]

(01-19-2015 05:08 PM)Marcus von Cube Wrote:  

(01-19-2015 07:00 AM)Paul Dale Wrote:  And it isn't heavily tested

and built.

And flashed. ;-)
I just updated to v3.3 3734 (calc_ir_full.bin) and did some tests.
Here are the results, as usual in d.my mode:

Code:

-18.032002   DATE->    x:18  y:3  z:-2002    // year now is correctly negative

-18.032002   D->J      989904                // returns correct JDN now

 989904      J->D     -18.032002             // returns correct date
                       Monday                // but still wrong weekday !

-18.032002                                   // another attempt, using DAYS+,
 ENTER  0    DAYS+    -18.032002             // still shows the same error
                       Monday                // in the weekday display

-18.032002   WDAY      7                     // Sunday is correct
                       Sunday                // obviously the 34s knows better ;-)

So there still is a bug in the weekday displayed along with the results returned by J–>D and DAYS+. Possibly other date functions are affected as well. On the other hand, the dedicated WDAY function returns the correct result.

BTW J–>D still accepts negative input. I think this should get corrected as well.

Dieter

[Marcus von Cube]

Pauli has done some more modifications. I've just built everything.

[Dieter]

(01-23-2015 12:14 PM)Marcus von Cube Wrote:  Pauli has done some more modifications. I've just built everything.

Thank you. I tried the same functions as in my previous post and now the results look okay. And negative JDN input now throws a Domain error.

Dieter

[Dieter]

(01-23-2015 05:21 PM)Dieter Wrote:  And negative JDN input now throws a Domain error.

That's fine, but I just noticed that on the other hand D–>J may return negative JDNs: the valid input range seems to be any date not earlier than 1 Jan 4800 B.C., i.e. –01.014799 which returns a Julian day number of –31776. Earlier dates, starting at 31 Dec 4801 B.C. (resp. –31.124800) throw a Domain error.

So another fix will be required that sets the limit from year –4799 to –4712. That's the year starting with JDN 0. If I got it right, it seems to be line 120 in date.c. ;-)

BTW, I see there is a compiler option INCLUDE_EASTER with code for calculating the easter date. Great! Why is this useful function missing in the current releases?

The code also shows that the LEAP? test accepts either an integer year in X or a date in the currently set format. I always thought that the former was required while the manual says the latter is needed ("Takes x as a date in the format selected, extracts the year, and tests for a leap year"). Actually LEAP? works in both cases. Walter?

Dieter

[rprosperi]

(01-24-2015 10:16 PM)Dieter Wrote:  Why is this useful function missing ?

I've followed this and related date handling threads out of curiosity, having no specific interest in date functions myself other than the occasional 'how many days old are you?', 'what day of the week was my birthday in 1999' and other party tricks.

Rather than "why is this useful function missing?" I would ask "why is this missing function useful?".

Not trying to judge at all, just mystified? Is the need for these negative dates and related functions related to astronomy?