> String "DOS" is absent from > https://en.wikipedia.org/wiki/Year_2038_problem. Has anything been > done or planned to deal with it in FreeDOS, or the legacy filesystems > it supports?
The UNIX epoch time is originally a 32bit integer in seconds, since 1.1.1970. Not defined to be signed, but often is. https://stackoverflow.com/questions/471248/what-is-time-t-ultimately-a -typedef-to That permeates through all sorts of software in UNIX. But: If any piece of software at hand is written "properly", i.e. using strictly the type "time_t" in its source code (and doing any manipulation in a safe way), then there's a good chance, that you're safe on a 64bit platform by merely recompiling your binaries from source - because the year 2038 has been known about since the dawn of UNIX, definitely in the time sync community. You are possibly safe on a modern 32bit platform as well, because the C type may be #defined with explicit length ("signed long int" vs. "signed long long int") rather than just "int" (would make the length automatically dependent on the target instruction set of your compilation pass). It's really down to whoever built your "distro" from source (kernel and libc) and how they defined time_t in the respective header file. Ahh this paragraph is just my fabulation. The stumbling stone here is, that you need to keep compatibility between apps and system libraries. For that, you can either define the length of time_t as fixed/explicit (which might hamper portability of binaries), or I could imagine a rule that the size of time_t shall follow the instruction architecture of the "target platform of compilation", making binaries portable in this respect... Allegedly, the year 2038 should only affect software at runtime. It is proper practice to AVOID using the binary allocation size of "time_t" (as defined locally) as part of time encoding in communication protocols, storage formats and UI output. So again, properly written software, including proper file systems, should keep you safe against the Y2038 problem. There is another Wikipedia entry though, where DOS *is* implied: https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs Apparently, some DOS-based "systems" are prone to a problem with the year 2080, depending on the format of calendar YEAR as kept in the RTC (two decimal digits since 1980). Not sure if this affects FreeDOS, or is an internal matter of the BIOS brand and build, or what. Next, the file timestamps in FAT are subject to a problem with year 2108. Allegedly the calendar year is stored in FS metadata as an 8bit signed integer i.e. 7 bits available, since 1980. => oh, 2080 and 2108. What a pity. I myself will have overflowed by then. Frank _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
