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.
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.
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.
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.
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.
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.
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....
We're a decade closer to the Epochalypse (
https://en.wikipedia.org/wiki/Year_2038_problem) now so it would be nice to see what's in store for 2038. I tried to set the system date on my TurboColor to January 19, 2038 and it wouldn't allow it. The latest date that I could set was December 31, 2037 just before midnight. That's understandable since the NEXTSTEP 3.3 Patch 3 Overview states:
'/bin/date' command didn't allow dates later than 1999 to be set
Apple reference #2328124, 2327723
ISSUE:
The '/bin/date' command didn't allow the system date to be set to any year past 1999. A secondary problem resulting from this error was that users of the Preferences application were unable to set a date later than 1999.
RESOLUTION:
The 'date' command now correctly handles two-, three-, and four-digit years for dates in the valid UNIX range (1 Jan 1970 00:00:00 - 31 Dec 2037 23:59:59). Two-digit years from 70-99 are interpreted as 1970-1999; two-digit years from 00-37 are interpreted as 2000-2037. Three-digit years from 070-099 are interpreted as 1970-1999; three-digit years from 100-137 are interpreted as 2000-2037.So the clock turned over to the year 2038 as expected but I'll have to wait another 19 days to see stuff go sideways as Preferences won't allow the date/time to be set beyond the year 2037. There's probably some command line mojo to advance the clock but I'll just let it happen on it's own.
I used Previous to test this. The moment where it goes beyond the maximum time in January 2038 is problematic. While NeXTstep 1.x seems to continue working and just switches back to 1970, NeXTstep 3.3 crashes.
On the other hand, booting a system of which the clock has ticked beyond the maximum time is not a problem. The clock will be set to some safe date during start-up. But there is no way to set the clock to the current date after January 2038.
Thanks Andreas, I'll scrub the test and save my filesystem.
In lieu of Tim Cook contacting us to offer updated source code or patches for NEXTSTEP 3.3 and OPENSTEP 4.2 (hopefully Apple's search bot picks that up) the easiest solution may be to set the system clock back. In 2038 the clock could be set back to 2010 as others suggested. Then use a Raspberry Pi or other SBC to act as an NTP modified time server and proxy to manage HTTPS timestamps and certs? The SBC could possibly be a modified NFS server too, resetting file dates newer than the modified date? Just thinking out loud here.
I would suggest actually rewinding from 2038 to 1982, just to extend the interval to twice as long. By the time it runs out again in 2094, probably zero people will be left to care... except some unfortunate souls running WorldWideWeb in a museum display. Meanwhile I'll only be 78 in 2066, so at least I'll still be around to care!
To fully necropost this thread: The 400 year interval is accurate, but irrelevant. Normally every year ending in 00 is not a leap-year, despite being divisible by 4. The year 2000, being divisible by 400, was a leap-year. This was done to cope with the fact that the solar year is slightly less than 365.25 days. The entire range of dates within the Unix epoch is only subject to the 28-year cycle.
That's a good idea to reset the clock to 1982. When I was doing some reading about the issue I came across this site (
http://www.dispersiondesign.com/articles/time/determining_leap_years) which also explains the leap year calculation. As an interesting side note the 68HC68T1 RTC chip used in some NeXT machines uses the "every fourth year is a leap year" rule so it would have failed to calculate correctly in 2100.
Quote from: Nitro on January 06, 2025, 03:07:19 PMThen use a Raspberry Pi or other SBC to act as an NPT modified time server and proxy to manage HTTPS timestamps and certs?
This is what I plan to do as I use a lot of older software that will not make it past 2037. I'll set up a Linux NTP server with an era number/offset to give me a new epoch year for all my legacy systems.
I use DB2 Enterprise Server v6.1 and v8.2 and both have IBM "perpetual" License Certificates with expiration dates of 2037-12-31. I also use ARCserve 2000 to backup my legacy systems and its perpetual license also expires in 2037. If 2038 wasn't bad enough, I use a variety of older Borland software and was recently surprised when Borland's INTRASRV.DLL server software time bombed on 9/13/2020.
After thinking about this a little more, there may be issues with setting the clock back to 1982. The installer and system utilities may have issues with the future dates of system files on the install CD. The older version of NEXTSTEP on GitHub does a check to see if the filesystem is younger than 1987.
https://github.com/johnsonjh/NeXTMach/blob/f6bdb9c3268f0eadc545d41bcc0564453b17001e/mk-108.1/next/clock.c#L189-L194I don't know if newer versions do a similar check (or higher level utilities) so it may be safer to keep resetting the clock back to 2010 in the years 2038, 2066 and 2094.