Y2.038K time_t

[ame]

Just a 'stupid' question!

What if I change the typedef for time_t from long to LONGLONG?

Wouldn't that fix the Y2.038K bug?

Or rather move it up a bit.... (.to a point where I'm no longer, and don't have to worry about it.)

// Anders


Thought I could organise freedom
how Scandinavian of me

[ALM]

I'm not sure about the answer but I hope your plans don't include "Programming for a living" 38 years from now.

This "bug" makes it comforting to know that my grandchildren (whenever they make it) will have a bright future ahead of them!

Cheers!
Alvaro

[ame]

Well I rather get it right the first time then sitting correcting bugs, especially someone elses

// Anders


Thought I could organise freedom
how Scandinavian of me

[Jeeves]

I wouldn't recommend changing the typedef for time_t...

MFC does supply a date object that will work past Y2038. It's COleDateTime, which can handle dates thru Y9999.

[Jerry Coffin]

Yes and no. If you re-defined it, then re-compiled the standard library using the new definiton, it might work, assuming the standard library code doesn't contain anything that "knows" about how a time_t is represented.

The real place to be concerned is with your own code that USES time_t. As long as you use it correctly, you use time_t as an opaque type. That means that when/if MS (or whoever supplies the standard library you're using at the time) can change the underlying type of time_t, modify the standard library as needed, and your code will continue to work after 2038.

I'd note, however, that the standard library suppliers still have over 35 years to work on this, and it's a MUCH better defined problem than the Y2K stuff. That means that there's nowhere near the difficulty involved in updating the code involved as long as YOU don't abuse time_t and act like you know about its internals rather than treating it as an opaque type like you should.

In particular, that means that anytime you want to "play" with a time_t, you need to convert it to a struct tm first. You can then make modifications at your leisure. Note that a struct tm uses an int for the year, starting from 1900. That means it can represent at LEAST a range from past 30,000 BC to past 34,600 AD. Of course, even right now, "int" is normally 32 bits, so the real range becomes approximately 2 billion BC to approximately 2 billion AD -- the 1900 offset hardly even matters anymore at that point.


The universe is a figment of its own imagination.