>> >> You can probably safely stop worrying about issues compiling dBASE code with Quicksilver at this point, can't you? ;-)
>>>Not really... There is the remote chance an accidental chroniton or tachyon burst that would transport me back in time a couple decades or so...
>>>And then there is that situation where one second after 2038.01.19 03:14:07 (UTC) I could suddenly find myself at 1901.12.13 20:45:52 (UTC)...
>
>> I think you'd do just fine. First, nobody would really know what's UTC. Or UNC. Or URL. Or pretty much any other annoyn(t)ment of this century ;). The harder question is why would the clock be 32-bit, and even harder - why would it start at that point in the evening? H. G. Welles? Didn't his trip start on the first day of the century?
>
>Back when I was a university student, I used to baffle my friends by sending them E-mail that had timestamps set in the past or in the future on the Unix machines. By setting the TZ environment variable to a large enough value for the UTC to local time offset to cause the offset from the base time (1970.01.01 00:00:00 UTC for Unix, 1980.01.01 00:0000:00 UTC for DOS) to be interpreted as a negative value. Since the timestamps displayed in the E-mail software are the local time values placed in the header by the sender, the manipulation of the TZ environment variable was sufficient to get the "teaked" timestamps to appear in the E-mail that I sent.

OK... for lurkers out there, I just had to see what's special about the two datetimes you mention above, so after a couple of tries, I got

?TRANSFORM({^2038.01.19 03:18:07}-{^1901.12.13 20:45:52}, "@0")

and there it was, 0xFFFFFFFE.

We've once lost the system clock on the VAX - a power spike fried some parts of the motherboard - so at every boot it needed the system time to be entered, with a very demanding syntax. I entered it right, down to the second, missed only the millennium. The year was 2988 ;).

When this was discovered, I remained calm. I knew we were safe, using Cobol and 2-digit year.