IMSL: NDYIN gets it wrong!

[rahzan]

IMSL NDYIN repotrd the wrong date for an input value.
An input of 1 should get Jan-1-1900 but one gets Jan-2-1900. Then there is another skip on day 59 where they miss the obvious leap year in feb and then the discrepency becomes 2 days. Things SEEM to be ok as the discrepency remains at 2 through 1/1/2000 than I have checked.

I would like someone at IMSL to comment on this so I can be sure other more recent dates esp around yr 2000 are not in error.

To save typing, use the code below and compare to the conversion in ms-excel.

use Numerical_Libraries, only: NDYIN
integer IDAY, IYEAR, MONTH, i
i=1
do while(i>0)
read(*,*)i
CALL NDYIN (i, IDAY, MONTH, IYEAR)
write(*,*) MONTH, IDAY, IYEAR
enddo
end

[TimP]

Are you saying that IMSL considers year 1900 erroneously to be a leap year? It's not "obvious" to me whether you are claiming that 1900 should have been a leap year. Wouldn't the insertion of a spurious leap day in February 1900 rectify the error you say occurs up to that time? If their tables are OK for years 1901 to 2099, what influence are we likely to have?

[Intel_C_Intel]

According to my reading of the documentation for IMSL, an input of 1 should return Jan-2-1900, since NDYIN returns the number of days since Jan-1-1900. Also, 1900 isn't a leap year, according to the U.S. Naval Observatory (http://aa.usno.navy.mil/faq/docs/leap_years.html). Microsoft are incorrect in assuming 1900 to be a leap year, see
http://support.microsoft.com/default.aspx?scid=kb;en-us;214326 for an explanation why. My suggestion is to trust IMSL, not Excel, in this situation.

[Steven_L_Intel1]

Notwithstanding the other posts, which I think are on target, if you want "someone at IMSL" (Visual Numerics, I assume) to read something, posting here is not going to be effective. Look for contact info at www.vni.com

Steve

[Jugoslav_Dujic]

Yes, 1900 was not leap year -- 100*(4n+1), 100*(4n+2), and 100*(4n+3) are not leap years; since one year is 365 days, 6 hours, and 14 minutes, these "compensate" for these 14'.

Off topic, but as a curiosity -- that particular reform was introduced in IIRC 16th century by pope Gregory; as result, few weeks in 15xx have never existed -- say, March 10 was followed by March 21.

Russian, Serbian and Jerusalem orthodox churches have never adopted Gregorian calendary (and Julian calendary was even state-official by the beginning of 20th century in Serbia and October Revolution in Russia) -- as result, Russians & Serbs celebrate Christmas on Jan 7.

Further, docs say that "the date corresponding to the number of days since January 1, 1900."; it was zerodays from 1.1.1900 to 1.1.1900. So, yes, I think IMSL got it right.

Jugoslav

[rahzan]

To sum up, IMSL really does have it right. The two days discrepency are the result of two different reasons.
1. The ms-excel/access definition is N days SINCE but rather STARTING WITH.
and
2. ms (as did I) incorrectly assumed 1900 was a leap year.

Still those of us who want to communicate dates with ms/access or excel should subtract 2 from whatever value these apps pass to get agreement.

It'd be nice if they put this source of discrpency in their docs, Tho' I hear vni does not read these msgs.

Tim

[Intel_C_Intel]

I figure that when year 2100 rolls around, there will
be a similar frenzy to 'y2k', when everyone realizes that
there's quite a few programs that have been written to
assume that any year divisible by 4 is a leap year.
Don't guess I'll be around for all the fun though....

[kdkeefer]

The real fooler is, as Jugoslvic pointed out, is not that "century" years are not leap years, *unless* divisible by 400 (2000 was a leap year). Since there (presumeably) where no computers in 1600 and who knows what the world (if it still exists) will look like in 2400 we may have witnessed a truly once in a dozen generation event. (Haley's comet was a bit of a disappointment too.)
Regards,
Keith