The base date for DOS file date/time stamps is 1-1-1980. Set the file modification date/time stamp to all zeros and a directory listing shows 1-1-1980.
Actually, the DOS file date/time stamp is 32 bits but it is stored in 2 16 bit words. One word contains year (7 bits), month (4 bits), and day of month (5 bits).
The other word contains the hour (5 bits), minute (6 bits), and second (5 bits). Note that the seconds field is too small to go all the way to 60, so Microsoft drops the low order bit. Last field actually counts in 2-second units.
Here's a graphical layout of the fields (use a monospaced font):
/* MS-DOS stores the file modification date & time in 2 16-bit words * in the following format: * * +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ * last write date: | (year - 1980) | month | day | * +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ * last write time: | hour | minute | second/2 | * +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ * bit positions: |15 11|10 9| 8 6| 5 0| */
So DOS file dates will overflow at the end of 2107.
The problem comes primarily at installation when, you are attempting to update an existing program. Often software vendors use the last update field, to determine which version of a file you are using. In the case where you are using a DLL file that has a date AFTER the roll over, the computer will not be able to recognize it as being the update, and you will get one of those famous "The file you are installing is older than the existing file" type messages.
So, the primary problem will be during installation of your program after the date of roll-over.
Comments: