To solve the whole time/date problem, I never understood why they don't
separate the two. Time could then be a regular integer, since there's
only 86,400 seconds in a day. Then simply make the date the number of
days (instead of number of seconds) from some arbitrary start date.
This would solve the problem nicely, since even a regular 16-bit
integer could hold a date up to 179 years from the arbitrary start date.
On 11/12/2024 6:30 AM, Frantisek Rysanek via Freedos-user wrote:
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
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
