Workarounds for the 2038 problem on NeXTSTEP?

Started by ardi, October 05, 2015, 05:26:23 pm

Previous topic - Next topic

ardi

Yes, I know we are still a couple of decades from it, but has anybody thought any workaround for the 2038 problem on NeXTSTEP? Of course the main difficulty is that the problem is hardcoded on every application because it's a limitation on the size of time_t, which is of course hardcoded at compile time.

Just thinking: does the calendar repeat exactly every N years? If affirmative, as a not too bad workaround, we could set the clock back to some year, and all dates would be wrong just by the year -and by a constant year offset-, while the days, the weekdays, and the month would be exactly correct. Not an ideal solution but perhaps not too bad.

ardi

Add-on: The Gregorian calendar repeats itself in cycles of 400 years if the information I found on the Internet is accurate. If this is correct, the "idea" I had about offsetting the year cannot be done because the UNIX epoch time is in 1970. And even if negative time would work, it wouldn't be possible to encode years older than 1901.

This means it is impossible to do a 400-year offset in the 32bit implementation of time_t, so my "idea" couldn't be used.

Considering time_t is hardcoded in every application that includes the corresponding header, maybe we've to assume NeXTSTEP won't be usable after 2038.

Another option can be to patch the libc library, so that standard functions that deal with time_t consider a new epoch time. If applications manage time_t values only through standard functions, it would be "fixed". But if any application does any custom math with time_t values which need to consider the UNIX epoch, then such apps would still fail.

Also, statically-linked executables could also fail, of course, even if we patch the system libraries.

jasonwoodland

I thought it repeats itself every 28 years. 1987's calendar is identical to 2015's.
How could it become unusable? Maybe network applications that require correct dates could be affected, such as HTTPS, I think.

ardi

Quote from: "jasonwoodland"I thought it repeats itself every 28 years. 1987's calendar is identical to 2015's.
How could it become unusable? Maybe network applications that require correct dates could be affected, such as HTTPS, I think.

I'm not sure if the 28-year cycle is always true. I cannot confirm it now. The Wikipedia article states the complete cycle of the Gregorian calendar takes 400 years.

Regarding the OS becoming unusable, well, it depends. First, time_t is signed. This means that it will become negative when it overflows in 2038. Will the OS and the applications honor a negative time_t, or were they coded with incorrect signed<>unsigned casts? This is clearly uncertain because in the good 'ol times of UNIX it was common practice to ignore compiler warnings. Very few people from that era used to compile with pedantic warnings while getting a zero-warning compilation.

Second, even if that doesn't fail and the signed arithmetic works fine, your filesystem dates will begin to show file dates at 1901, with also files with dates in the future. I don't know how NeXTSTEP will behave in such scenario, but some UNICES don't like to have dates in the future.

Regarding the magnitude of the impact, it's not uncommon for an application to include "time.h"

Of course, even if none of this fails and NeXTSTEP and all the applications work correctly, weekdays will be wrong.

My "idea" for applying a year offset was considering to also perform a clean install, so that there're no dates in the future in the filesystem.

ardi

As an addition to what I said, it's easy to guess utilities or applications that can fail or behave incorrectly in 2038. One example is "make", used for building many applications, as well as for building TeX documents and in general for managing files that depend on other files.

If you try to compile on 2039 source code written in 1990, "make" will think that the object files and the executable are always outdated no matter if you recompile. Of course if you "touch" the whole source code so that all files have their date in 1901, it should work as expected (supposing "make" doesn't perform any incorrect signed<>unsigned cast on time_t values).

This is just a dumb example. With a little of imagination you can guess many other situations that could behave incorrectly or unexpectedly after 2038.

cubist

Quote from: "ardi"
This is just a dumb example. With a little of imagination you can guess many other situations that could behave incorrectly or unexpectedly after 2038.

Time for a little empiricism...  Someone interested in this could make a few clones of their system and see what happens when the clock is jumped forward.  Booting on both sides of the magic date.

neozeed

time_t is a signed integer.  the only hope is to change it to unsigned to double the lifespan of UNIX.  since we don't have source it would be a binary patch.

then everything else that calls, and manipulates it too must be updated.

This will be a MASSIVE undertaking....
# include <wittycomment.h>