I don't believe there are Y2K problems in acedb code. Obviously the underlying
operating system must be Y2K compliant because it makes system calls. Dates
are stored internally in an acedb-specific format that knows the precision of
the date-time, e.g. day only, seconds, month only etc. These always write
out as 4 digit years, but the parser will recognise 2 digit years, and map
values greater than 50 to 19xx, 50 or less to 20xx. So there is a potential
Y2050 problem there if you use that feature in data. It looks like we set
a maximum year of 2053 anyway, so there is a serious Y2053 problem.