I recently stumbled upon a time.h implementation from a hardware/software supplier that did not have its epoch time starting at midnight, Coordinated Universal Time (UTC), 1 January 1970 as expected.
Having always believed that this was standardized as a part of the C-standard I was surprised that this part was in fact not the case. A brief scan online showed that most, but not all, time.h implementations does in fact start it “time” in 1970.
This particular hardware/software supplier had instead chosen to have its epoch start at midnight UTC-6 Jan 1, 1900.
As I was working with a trace log implementation at the time, where I had logs on different types of processors being gathered on one processor it was important for me to have each trace entry’s time stamp be correct at least down to the second, to be able to match these trace logs between the processors correctly.
Some more searching on the matter showed that RFC 868 has a part defining the difference, in seconds, between these two times, giving to hand that 2,208,988,800 seconds have passed between these dates. Now of course, this would not be too hard to calculate by hand, but it’s always nice to be able to give a good reference to magical values like this that you leave behind you in your code.
On a side note, this particular implementation would wrap somewhere around 2036. While it is unlikely that any code we deliver today would still be running in some 23 years time – it’s still not that far away. Also, choosing a different epoch that most time.h implementations out there is just begging for problems – and error reports from your customers.