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...
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)
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.
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.
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. ;)
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? ;)