The time:verify-date function in LIBLSP; TIME (LIBDOC; TIME >) is broken

[eswenson1]

The time:verify-date function, among other things, verifies that the supplied day of the week (DOW) matches the computed one for a given date. If is not working correctly now (Y2K issue?).

This function is used in time:print-date and because of the above failure, time:print-date raises an error. time:print-date is used in some of the Macsyma tools.

I commented out the check in time:print-date in LIBDOC; TIME KMP8 (the original was TIME KMP7). This ticket serves as a reminder to fix time:verify-date and then reenable the check in time:print-date.

[eswenson1]

I couldn't follow the algorithm used in to compute the DOW. I see different algorithms on the 'net. Perhaps we should just rewrite this function to use a known-good algorithm that works correctly for both dates in the past and current dates.

[atsampson]

This isn't (exactly) a Y2K issue; it's a leap year rule issue. At present, TIME:ON-WHAT-DAY-OF-THE-WEEK? is only correct until the end of February 2000.

A is the number of years adjusted so that years start on March 1st, which means the leap day falls at the end of the year. The last few terms in the addition implement the leap year rules. The 100 and 400 rules are correct, but there's also a (// A -2000) term in there, which makes years divisible by 2000 not be leap years. That shouldn't be there; there's no such rule in the Gregorian calendar (although it was occasionally proposed prior to 2000, since it would have made the average year length a bit more accurate, so perhaps the author of this was thinking of one of those proposals).

With the (// A -2000) term removed, I've checked that this code produces correct results for every day from 1753 up to at least 10000. And if people are still using both ITS and the Gregorian calendar come 10000, someone's going to have to go through the code and make it handle three-digit centuries anyway...

(There's a comment saying This code adapted from JONL's package MC:LIBDOC;DOW >, so I guess #726 needs the same fix. Do we have the source for that, and does it say any more about where the algorithm came from?)

[eswenson1]

Thanks! I’ll fix. And yes, my next commit will include DOW, which I will. Also fix.

[eswenson1]

Even with the above fix, this code still is wrong:

(time:on-what-day-of-the-week? 22. 07. 2018.)
5

5 = Saturday (according to this package). But that day is a Sunday.

[atsampson]

Weird - this modified code returns the right value for me:

*:lisp

LISP 2154
Alloc? n
*
(load "date lisp")
T
(weekday 22. 07. 2018.)
;Loading DEFMAX 98
;Loading MLMAC 92
;Loading LET 98
6

There isn't a compiled version of the original code sitting around somewhere, or something like that?

[eswenson1]

Can you make available your version of TIME LISP so that I can compare with the version in DB, which is in LIBDOC; TIME >?

[atsampson]

I haven't changed LIBDOC; TIME > at all - when I was debugging it, I copied just that function to another file (attached to the previous comment) and modified it there.

On my ITS system, I've just checked that LIBDOC; is the same as current master, i.e. there's TIME KMP8 without your fix and TIME KMP9 with it. The latter seems to work if I load it explicitly:

LISP 2154 [... snip Loading messages etc. ...]
(load "libdoc; time kmp8")
T
(time:on-what-day-of-the-week? 22. 07. 2018.)
5
(load "libdoc; time kmp9")
T
(time:on-what-day-of-the-week? 22. 07. 2018.)
6

[eswenson1]

Interesting! Does that suggest that since DB has both kmp8 and kmp9 that the wrong one is getting compiled? I wonder if there is an explicit reference to kmp8 version in the lisp.tcl file.

[eswenson1]

I checked. And there is. I’ll fix.

[eswenson1]

See #1081

[eswenson1]

Resolved by #1092