Microsoft wisely updated time_t and the ATL CTime and CTimeSpan to use an int64 under the hood (from a int32), this is good except when we have those data types in our interfaces, and now we have broken backwards compatibility.
time_t has a a define you can use force time_t to stay a int32 _USE_32BIT_TIME_T. Unfortunately CTime/CTimeSpan do not respect this. One of our DCOM components packs arrays of objects into a stream. To make the game more fun one object element was a CTime and another was a variable length string. The fun began when another teams Delphi tool unpacked these streams and went off into the weeds because the packed objects were different lengths, thus the variable length string’s length was in a different place. Lots of fun debugging that one.
Anyway, the current solution was to change the object’s to use int32’s instead of CTime/CTimeSpan, and downcast the int64 result from .GetTime() and .GetTimeSpan() to a int32. Now our interface is restored. Ok so we are not future proof, and that app will start to behave fun some time in the future, but this just adds to the code paths that need retiring. Oh the joys of large old systems.