The real way to deal with time/date bugs forever is a 512-bit timestamp, with a 144-bit subsecond part and a 368-bit second count. This provides resolution on the order of 1 Planck time for over 10^100 years, which should be sufficient for as long as computers will be needed, and to cover all foreseeable technological improvements in clock precision [citation needed].
On Tue, Nov 12, 2024, 09:50 tsiegel--- via Freedos-user < freedos-user@lists.sourceforge.net> wrote: > 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 >
_______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
