[fpc-pascal] Error compiling on AROS/m68k: 1980-0-0 is not a valid date specification

[Karoly Balogh (Charlie/SGR)]

Hi Charlie,

On Fri, 18 Dec 2020, Karoly Balogh (Charlie/SGR) via fpc-pascal wrote:

> > I also see that the pre-installed version was installed with the clock
> > in the system was set to the start of the Amiga Time (1.1.1978). Might
> > that create a problem?
>
> Actually, yes. If I reset the timestamp of the system unit to 1978-1-1,
> 00:00:00 (the start of the Amiga Epoch), I can reproduce the issue on my
> system and installation (which is a real '060 + AmigaOS 3.1).

So the root cause is, Amiga follows the non-Unix codepath for
DateTimeToFileDate inside the sysutils unit, which is artificially limited
to dates between 1980 and 2099:

https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/sysutils/dati.inc?annotate=47808#l1260

This is super old code, it was already there 15 years ago, at the time of
the SVN import... I guess the original intention was to keep us
compatibile with MSDOS/old FAT file timestamps, which can actually
represent dates between 1980 and 2107. (So no idea where 2099 comes
from... Because Windows actually counts file dates from 1601 (fix me?),
and more modern FSes no longer have the limitation mentioned above
anyway.)

Anyway, this means FileAge function for Amiga will return zero for dates
before 1980, which then causes various havoc down the line. More
specifically, later the compiler calls FileDateToDateTime from (see
globals.pas filetimestring()) to print a debug message into the verbose
log (normally thrown away, actually, but available as fpcdebug.txt with
the -vv parameter), which then blows up in sysutils/EncodeTime, because
zero is an invalid file timestamp actually as far s the MSDOS timestamp
format is concerned, because you get zero as day and month (and year too,
just the code adds 1980 anyway... :) )

Yuck. :P What a nice juicy can of worms... Found just because someone used
a buggy LhA to decompress Free Pascal on Amiga... :D

I'm not touching this for any other platform, because ... Just no. :D But
as the FileAge return value and the FileDate format should be OS specific,
on the mid-run I'll migrate the Amiga code away from the non-Unix
codepath, to something custom. Probably to something very similar to the
Unix codepath, but counting the Epoch from 1978-01-01 instead of
1970-01-01... Or a packed/smaller version of the AmigaOS DateStamp
structure. This has other advantages, for example the Amiga RTL will no
longer be limited to 2 seconds resolution when working with file
timestamps, another MS-DOS/FAT legacy coming from the generic code paths.

Thanks Carsten, for this report. As much as we usually get invalid reports
regarding the Vampire, this was genuinely useful.

For now, please use the workaround I mentioned in my previous e-mail,
because this will take a while to fix. I'll also try to get a quick fix
into the compiler, to make it not blow up with an exception at least,
because the compiler code seems to be prepared to work with invalid
timestamps otherwise.

Cheers,
--
Charlie