The MFC CTime class uses the time_t "structure" internally to store its data. This means that it stores time/date as a signed 32-bit count of milliseconds since January 1, 1970. While this makes it safe for the dreaded year 2000, this counter will wrap sometime in early 2038. As a result, CTime stops functioning for any date from January 2038 and up.
Now I expect that all of my users will have upgraded to version 42 of my program by that point, but thinking like that is where the Y2K bugs came from in the first place. Besides, when customers or management press for information on Y2K compliance, it can be embarrassing to have to explain why the year 2038 is in the critical path. It's just easier to fix it.
So without further ado, I introduce my solution. I have re-written the CTime class using the tm structure in place of the time_t structure for internal storage. My new class is CGoodTime.
I have attempted to keep the interface consistent with the original CTime class with the intention that this would be a straight drop-in replacement. I believe I have succeeded in this goal with three exceptions.
- Methods that have time_t as parameters or return values in CTime have tm values in their place, since interfacing with time_t's would defeat the purpose.
- I dropped support for the operators which return CTimeSpan. I didn't need these, so I leave it as an exercise to you to implement these if you need them.
- I dropped support for the '#' character in the Format strings. See 2.
The sample project I've included here uses the CGoodTime class and the CTime class to produce text output of all ways a time can be represented with the the Format function. A radio button controls whether the output is in local time or Greenwich Mean Time. For dates prior to 2038, the two strings should match exactly. For dates 2038 and later, CTime does not produce output.