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.

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.