Subj : Re: Operating Systems
To   : AKAcastor
From : tenser
Date : Tue Apr 09 2024 12:08 am

On 07 Apr 2024 at 08:02p, AKAcastor pondered and said...
 
 AK>  pF>  I thought the 2038 problem was a unix time_t issue?
 AK> 
 AK>  t> Depends on the Unix and the definition of `time_t`; on
 AK>  t> any reasonably modern system that's an `int64_t`.  It's
 AK>  t> really just old binaries or old versions of the OS.
 AK> 
 AK> DOS has its own date/time formats, but it is also common for software to
 AK> convert between those and unix timestamps - so I think we will see many
 AK> DOS programs directly affected by the year 2038 time_t overflow.

Again, "Unix timestamps" have changed definition and meaning
over time.  The issue is if someone tries to stuff the number
of seconds since 1970 into a 32-bit signed integer; `time_t`
these days is 64 bits, even on 32-bit machines.  But also, one
is running DOS binaries under some sort of DOS emulator.  In
that case, one can artificially inject a date in the past into
the emulator, avoiding the entire issue, unless one really cares
that some random MS-DOS programs know the proper date sometime
in the late 2030s, which I found dubious.

--- Mystic BBS v1.12 A48 (Linux/64)
 * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

.