Paul Berkowitz wrote on Sun, 25 May 2003 09:17:09 -0700:

>On 5/25/03 8:59 AM, "Nigel Garvey" <[log in to unmask]>
>wrote:

>> It works with every date I've tested so far in the AppleScript date
>> range, including those that come before 1904. Because of a Mac OS
>> date-subtraction bug, French Vanilla crashes on dates before 1904. (I
>> know what you're thinking, but it's a vulnerability nonetheless.)
>>
>> It turns out that the bug doesn't kick in when a later date is subtracted
>> from an earlier one, ...

>I came upon a date (and large number) addition-of-a-negative-number bug,
>which could put you back a whole Mac epoch (c. 136 years) so you found
>yourself in the 1800's instead of 1972. In that case subtraction of positive
>numbers was the solution. What's the subtraction bug exactly?

Hi, Paul. I think I remember you bringing up the "epoch" problem on one
of the lists some time back. I'll have a look through my archives later
on.

The subtraction bug that affects French Vanilla manifests itself when you
have two AppleScript dates, both of which are earlier than 1904, and you
try to subtract one from the other. There's an execution error: "The
result of a numeric operation was too large." As I discovered the other
evening, though, the error doesn't occur if the dates are not equal and
the later one is subtracted from the earlier one.

Chris Nebel said it was due to a problem with one of the operating
system's underlying math routines. Basically, pre-1904 dates are
represented by negative numbers (I think). After a subtraction of these
that should give a positive number of seconds, the routine responsible
misinterprets the combination of processor flags (negative, overflow, and
carry) and deduces that the result is a number too large to be
represented in the given number of bytes. (I never fully got the hang of
this when I dabbled in 68000 assembler a few years ago.)

>BTW, do you actually meant the opposite of what you say here:
>
>> It turns out that the bug doesn't kick in when a later date is subtracted
>> from an earlier one, so English Fudge subtracts the January date from the
>> original instead of vice versa.
>
>Won't the January date be _earlier_ than the original one, so don't you want
>to subtract the original date from the January one, not vice versa, if you
>want a later-from-earlier?

You're absolutely right. Thanks for noticing that. And I read it so many
times before posting it, too. :-(

>And is there really a bug with subtracting a
>number from itself - not getting 0 - if the dates are exactly the same in
>the case of original dates in January? You still need to subtract 1 to get
>an earlier January date?

That's the case on my machines. With dates before 1904, only subtracting
a later from an earlier will work. The actual amount knocked off the
January date can be anything be within a certain range - which I haven't
bothered to determine. I used 1 as a cautious bare minimum.

NG