2038 Problem

[winbatch]

Hi,
After completing my Date class, I realize that I am suffering from the 2038 problem. (As described here-> http://pw1.netcom.com/~rogermw/Y2038.html ). Does anyone know which libraries (or which code) I need to switch to on *nix systems to overcome this? (I know windows has someting like mktime64 (instead of mktime).

Google returns lots of info about the problem, nothing really about the solution...

Thanks,
Winbatch

[Dave Sinkula]

Could you describe your problem with this in more detail?

[winbatch]

Sure, basically I have a date class that I wrote which wraps time_t. time_t and its associated functions mktime, localtime, etc do not function after January 19, 2038. (This is a known issue and is not related to my specific class). Attempts to use dates greater than that cause undefined behavior. (Basically attempting to go over the maximum value of an int).

My question was whether there are replacements for time_t (standard C++ only) that can deal with this. (I'm covered on windows since they created a time_64)

[Dave Sinkula]

From some bits I'd read a while ago, that I haven't been able to find again, it's a problem for the generated executable -- not necessarily the source code. For example, in 2011 the world runs 64-bit workstations: you recompile with a 64-bit unsigned int-based time_t and you're fine for a good while. Running today's application for the next 33 years, however, would be problematic.

But unfortunately, I haven't dug up any current non-standard replacement functions.

[winbatch]

Right - basically I'm looking to see if this:

64-bit unsigned int-based time_t

exists already on unix. If so, I would compile with it now..

[Dave Sinkula]

Which flavor of Unix (not that my searches will be any better than yours)? And what target processor?

[winbatch]

SunOS ... 5.8 Generic_108528-14 sun4u sparc SUNW,Sun-Fire-280R

(Basically, solaris 8), using Forte 7 compiler.

[sinrtb]

SunOS ... 5.8 Generic_108528-14 sun4u sparc SUNW,Sun-Fire-280R

(Basically, solaris 8), using Forte 7 compiler.

you should be able to write an algorithm for this problem. the problem does not lie in the executeable it lies in the class you are using, all it does is takes the amount of seconds since sometime in 1969 and using division seperates it into days years and dates. because this is seconds the MAX_INT_SIZE is reached fairly quickly. but if you were to take the raw data and and find a away to see if it "rolled" you can just add the return value to the max int value in an array form then do all your calculations with that number. there is a big number factorial calculator that i belive does this on this site.
Just my thoughts.

[winbatch]

I would prefer not to have to rewrite all of the calculations performed by mktime, localtime, etc. just to accomplish this....

I've already fixed my code on windows by simply using __time_64_t instead of the time_t. I'm just looking for a unix equivalent.

[Dave Sinkula]

all it does is takes the amount of seconds since sometime in 1969 and using division seperates it into days years and dates.

That sounds a little naïve; dates and times do have their many little issues.

[Dogtree]

If you really need dates beyond 2038, you have no choice but to avoid time_t and the standard functions, which means either hand coding the algorithms or using a third party library. That's the solution that people use when they need very old dates (where they discover the "Satan's armpit" of pre-gregorian calendar dates) or long predictions of the future. But for most uses of dates, you can play the wait game and the problem with fix itself when your implementation converts to 64-bit time_t's or your application stops being used. ;)

[winbatch]

For windows, I use __time_64_t. What 3rd party libraries exist for use on SUN?

[Dogtree]

As far as I know, the only way to get a 64-bit time_t on Solaris would be to use a 64-bit version of Solaris. As for third party libraries, I don't know of any without a thorough web search, but I would be surprised if sourceforge and friends didn't provide one. boost::date_time can handle what you want, but that's kind of like using std::string to handle the work for your own String class, no? ;)