Q: Offsetting time_t in C++ I am dealing with timestamps generated by a system where the epoch is not the standard UNIX epoch of seconds since midnight of Jan 1, 1970 (it starts somewhere in 1965 instead). This question is kind of related. So, I have a "fixup" function to deal with this offset:
time_t fix_time(uint32_t raw_time)
{
    const int32_t epoch_offset = 157680000; /* offset wrt UNIX epoch */
    time_t fixedTime = static_cast<time_t>(raw_time - epoch_offset);
    return fixedTime;
}

and continue using the standard library functions in rest of the code: 
uint32_t raw_time;
time_t timestamp = fix_timestamp(raw_time);
struct tm timeinfo;
gmtime_r(&timestamp, &timeinfo);

It seems to work as intended (held up to a mix of real and synthetic test data, so far). However, is there a better way to deal with this scenario? Are there any subtle ways in which this might break? Additional info if it matters: the timestamps are spread out over 1981 to the current day and the program runs on a Linux machine.

A: time_t is already a C legacy. For your own time, you should really make a class. The main advantage of such a class is that you can avoid unintended behavior. You define which operators make sense, and operator^ probably does not. You define which conversions are supported, and that's probably just to time_t (if at all - the alternative is a .getCtime() method)
Internally, you can use an unsigned long which gives you at least 68 years extra. The Y2038 problem is because time_t is signed, and the UNIX era runs from 1902 to 2038. 
