Jesus Valdez writes:
>Stan Sieler wrote:
>>
>> Wirt writes:
>> ...
>> > The question is: is that day calculation correct? Although when I
>> ...
>> > However I was very pleased at HPWorld '96 when Vladimir Volokh wanted to
>> > show me the new calendar features in MPEX that Eugene had recently
>> > programmed into MPEX (which, BTW, also fails on December 31, 9999).
>>
>> (Fails after 9999-12-31, I think you meant)
>>
>> > Thus, after a fit of dueling calendars on side-by-side terminals, we
>> > demonstrated to each other that our two calendars agreed perfectly. That
>> > demonstration was quite reassuring. Eugene's date calculations so far
>> > have been the only completely independent verfication that QueryCalc's
>> > calendar is correct -- or at least wrong in the same way MPEX is.
>>
>> >From HP-UX & AIX:
>>
>> cal 12 9999
>> December 9999
>> Sun Mon Tue Wed Thu Fri Sat
>> 1 2 3 4
>> 5 6 7 8 9 10 11
>> 12 13 14 15 16 17 18
>> 19 20 21 22 23 24 25
>> 26 27 28 29 30 31
>>
>> BTW, even a "standard" routine like cal varies from Unix to Unix:
>>
>> HP-UX: cal 1 10000
>> Bad argument
>>
>> AIX: cal 1 10000
>> 0702-001 Specify month as number between 1 and 12
>> Specify year as number between 1 and 9999.
>>
>> POSIX on MPE/iX, OTOH, appears to be implemented by a Stanford fan:
>>
>> MPE/iX: cal 1 10000
>> cal: not found
>>
>> :)
>>
>> --
>> Stan Sieler [log in to unmask]
>> http://www.allegro.com/sieler.htmlI
>don't see any problem with the year 10000 and MPEX:
>% CALENDAR DECEMBER,10000
> December 10000
>
>
> SUN MON TUE WED THU FRI SAT
>
> 1 2
> 3 4 5 6 7 8 9
> 10 11 12 13 14 15 16
> 17 18 19 20 21 22 23
> 24 25 26 27 28 29 30
> 31
Actually, MPEX seems to be cool out to 32766, which is a relief :)
calendar dec,32766
December 32766
SUN MON TUE WED THU FRI SAT
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
32768 causes an error message, which is to be expected:
calendar dec,32768
Error: DATEBUILD passed bad year, month, or day (-32768/12/1).
32767 causes MPEX to go into a (seemingly) endless, CPU munching loop.
Fortunately, VESoft has a little bit of time before they need to fix this.
:)
-Bob
[log in to unmask]
|