Anssi Seppälä wrote:
> The leap year is one case, but there is more: eastern, ISO week numbers
> etc. that are often needed. My experience goes to the 1980's when I
> found an APL function DATUM. It did great job many years until it did
> wrong somewhere after 1990. The conclusion is that no programmer has
> the time to carefully check the algorithm over many future years.
> Writers of Calendrical Tabulations have done the job seriously and
> professionally and therefore I trust on them. When I use calendrical
> information in my applications I allways check it with published calendars.
>
> Anssi
>
> At 02:21 30.12.2006, you wrote:
>> Are there any particular examples how this book is
>> more precise than following the mentioned formula,
>> or using the dates script.
>>
>> --- Anssi Seppälä <[EMAIL PROTECTED]> wrote:
>>
>> > My experience is that the APL/J calendrical algorithms are allways
>> > unreliable. The testing is allways insufficient. My choice was to buy
>> > Reingold&Dershowiz: Calendrical Tabulations 1900 - 2200. There I find
>> > reliable data and put that into the applications.
I don't think anyone has yet found a problem with J's date handling.
This thread was initiated by someone who thought there was an error, but
quickly admitted his mistake.
Nevertheless, it is important that the date routines be reliable, and
the suggestion that they may not be is a concern. Are there standard
tests that should be run? Obvious ones like the following seem to work
correctly:
load 'dates'
a=. (i.1e5) + todayno 1900 1 1
b=. todate a
a -: todayno b
1
{:b
2173 10 15
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
