Could you describe your problem with this in more detail?

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.

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..

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

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.

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.

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