How stored date and time information?

What does it matter that 2038 is next door?

Are you afraid that your device will fail to know if it has temperature values from 2038 or if the recorded value is from 20:45:52 Friday 13 December 1901?

Is it really (?) a problem for your software to figure this out? Will you really (?) have a log that already today contains readings from before 1970?

The magic thing happening in 2038 is just that a signed 32-bit time value will become negative - if treated as 32-bit unsigned, you'll manage until the year 2106.

And if you decide to use time base 2015-01-01 00:00:00 as "time zero" instead of the unix epoch of 1970-01-01 00:00:00, then an unsigned 32-bit will give you an additional 45 years meaning your poor logger will have time stamp values turning around in 2151.

So exactly how long do you expect to keep that recorder running, before it gets too old and should be replaced with a newer device? If you have ample room in your EEPROM, you could use a 48-bit or 64-bit value instead of a puny 32-bit integer. In the end, a binary value ticking one step per second is the smallest storage format you can use to store time with one-second resolution. Then you just need to decide how many bits wide that binary value should be, and the correlation between the value zero and some "normal" almanac time.

In your posted examples, it doesn't even seem like you need one-second resolution, given that you posted times in minutes - and with 15 minutes between the two samples. A 16-bit unsigned integer where each tick represents 5 minutes would cover 65535*5 minutes which is over 227 years. If it ticks with a 15-minute quantum it would cover 682 years. And if you always sample at a fixed time interval, you don't even need to store the individual time stamps - it's enough to store the start time and then just store the temperature values. Just remember what to do if you need to replace the battery, since rather few microcontroller-based devices actually manages hundreds of years of uninterrupted service...

If your samples are taken at irregular times you can still avoid storing huge absolute times for each sample by instead storing the delta time since the previous sample. You could maybe store a full time stamp every 100 samples to avoid the need to run through the full sequences of samples just to be able to compute the time stamp for the final reading.

So why do you end up seeing lots of problems with your data logger? Isn't the world full of solutions where a huge number of different solutions all will be good enough? There almost never exists any "best" solution to a problem - "best" just depends too much on the specific needs. And you haven't described your specific needs - you probably haven't even yourself figured out what your specific needs are.

As Per points out 32-bit 1970 Epoch numbers go out to 2106, many RTC implementation just deal with 1901 thru 2099 as it simplifies the leap year logic.

Windows has a 64-bit format

Doing calendering from any epoch isn't that complicated, though a lot of people do screw it up, and don't test their code, so you should always verify the corner cases on stuff you pick up off the internets.

The 2038 thing is a bit of a red herring, sure some old crap is going to fail, but anyone putting any thought into things will be fine.

"many RTC implementation just deal with 1901 thru 2099 as it simplifies the leap year logic."

The RTC tends to be the weak links. How to set the initial time. How to handle drift. How to handle leap years. Leap seconds. Time zones. Daylight savings. Over-the-air or networked protocols. Power failures/battery changes. Moving the device over a time zone boundary or date boundary. Logging when RTC was synchronized, and how much forward/backwards the time was corrected. How long the RTC may be allowed to operate standa-lone without synchronization. How to know if the supply voltage is high enough that the RTC operation can be trusted.

There are so many assumptions that needs to be documented. So many things that has to be either ignored or supported/tested/documented/...

The time stamps of the individual measurements aren't worth much if there isn't confidence in the time used by the RTC.