Re: Y2038 - best way forward in Debian?
What if we define an epoch to be 50 years and the epoch number becomes
part of how the computer keeps track of the date. Something similar
is done in astronomy I think, star charts always have an epoch. So
epoch 0 was 1970, epoch 1 is 2000, epoch 2 is 2050. Then we can keep
a time_t at 32 bits. Things like strptime() and strftime() and
ctime() would need changing but since they were valid in epoch 0
they'd only need to change for epoch 1 and later. A day will continue
to be 86400 seconds of a 32-bit number but every 50 years the epoch
would change. Dates can overlap epochs so 2020 could be part of epoch
0 and epoch 1. The year part of a time_t and struct tm ceases to be
absolute like an hour isn't absolute on a 12-hour clock. It's
probably been thought of.
On 2/14/20, John Goerzen <jgoerzen@complete.org> wrote:
> On Tue, Feb 04 2020, Steve McIntyre wrote:
>
>> Arnd scanned the library packages in the Debian archive and identified
>> that about one third of our library packages would need rebuilding
>> (and tracking) to make a (recursive) transition. We can see two
>> different possible routes to follow:
>>
>> A Follow a similar path to last time (rename library packages). This
>> will allow us to do partial upgrades, but the cost is that a vast
>> number of packages will need work to make this happen,
>> *potentially* building library packages twice to allow us to
>> continue both 32-bit and 64-bit time_t support forwards for a
>> while. This effort will be *needed* only for the sake of our 32-bit
>> ports, but would affect *everybody*.
>
> The thing that we have to remember is that an operating system is a
> platform for running software. This problem is rather thorny, because:
>
> 1) Some software is provided in only binary form and cannot be
> recompiled
>
> 2) Some software can be recompiled but makes assumptions about the size
> of variables, may use int instead of time_t, and other assorted
> messiness
>
> 3) Some software is going to break now, due to forward-looking time
> calculations, and for others, it may be fine (or nearly so) even past
> 2038 due to timekeeping being only ancillary to its purpose. For
> instance, I have some old games that are binary-only and really don't
> care what time it is.
>
> This option #1 sounds like a significant effort (because not only would
> we need two versions of libraries, but also of include files). But it
> certainly passes the "correctness" test better than your option #2.
>
> John
>
>
--
-------------
No, I won't call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
Reply to: