NeXT Computers Forum Index NeXT Computers
www.NeXTComputers.org
 
Log in to check your private messagesLog in to check your private messages

Log inLog in  RegisterRegister


Profile  Search  Memberlist  FAQ  Usergroups
Workarounds for the 2038 problem on NeXTSTEP?

 
Post new topic   Reply to topic    NeXT Computers Forum Index -> NEXTSTEP / OPENSTEP Software
View previous topic :: View next topic  
Author Message
ardi



Joined: 11 Jun 2014
Posts: 85

PostPosted: Mon Oct 05, 2015 10:26 am    Post subject: Workarounds for the 2038 problem on NeXTSTEP? Reply with quote

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.
Back to top
View user's profile Send private message
ardi



Joined: 11 Jun 2014
Posts: 85

PostPosted: Fri Oct 09, 2015 10:10 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
jasonwoodland



Joined: 26 Mar 2014
Posts: 18
Location: Melbourne, Australia

PostPosted: Sat Oct 10, 2015 10:14 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
ardi



Joined: 11 Jun 2014
Posts: 85

PostPosted: Sun Oct 11, 2015 1:39 am    Post subject: Reply with quote

jasonwoodland wrote:
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.
Back to top
View user's profile Send private message
ardi



Joined: 11 Jun 2014
Posts: 85

PostPosted: Sun Oct 11, 2015 2:27 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
cubist



Joined: 20 Sep 2007
Posts: 246
Location: Cambridge, MA

PostPosted: Sun Oct 11, 2015 12:09 pm    Post subject: Reply with quote

ardi wrote:

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.
Back to top
View user's profile Send private message
neozeed



Joined: 15 Apr 2006
Posts: 691
Location: Hong Kong

PostPosted: Sun Feb 07, 2016 12:13 am    Post subject: Reply with quote

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>
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    NeXT Computers Forum Index -> NEXTSTEP / OPENSTEP Software All times are GMT - 7 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum



Powered by phpBB © 2017 phpBB Group