What timestamp would have the best space efficiency with a 10 year span and 1 second resolution?

For a low end embedded microcontroller (8-bit), which timestamp structure would be smallest? I'm considering custom ones too. Because of computing power is very limited, it's also important to reading second, hour, or day etc. should be fast too.

This question covers my question, but i need to represent next minimum 10 years with resolution of second.

Update: I will store many timestamps in limited EEPROM space. So size开发者_StackOverflow efficiency has more weight on my case. Calculations (determining current timestamp is greater than another 2 or 3 one, displaying current timestamp on a custom design lcd) generally takes place on every second.

---

i need to represent next minimum 10 years with resolution of second

If you use an int32_t you're good until 2038 with these timestamps, and with uint32_t you can cover until 2106. Using localtime, gmtime and such you can convert them into struct tm if you need and extract the day, month etc.

---

This depends a bit on what you want to do with said timestamp and where it will come from.

Often in embedded situations the system will have a RTC (Real-Time Clock), do you have one? Or are you keeping track of time using the processors clock and or a 1Hz timer? If you do have an RTC I would be inclined to use the format from the clock and save any further processing.

Also relevant is whether you need to process this timestamp locally? If you need to work with it on the micro itself there will be distinct benefits to saving it in a format similar to that you need. For example if you need to display the date on a screen saving it in the packed format similar to that of the answer you already linked makes sense.

Generally, though for most embedded work I find as already suggested, using a 32-bit unsigned integer representing seconds from whatever epoch you choose is best. This is a good choice if you have to compare values as it is simple arithmetic comparison.

As per the BCD decimal there are quite a few questions about converting out of BCD for example, whilst that question was originally C# the answer should be almost identical in C.

---

Since π seconds is a nano-century (or 31 million seconds is one year), you need to be able to represent values up to 3.2×10⁸ to store up to 10 years worth of data. So, you need at least 29 bits to store such values, which makes a 32-bit number the obvious choice. You need to consider how you are going to define your epoch - the start date for time 0. But a 32-bit signed number can store up to 68 years worth of seconds (think Unix; 32-bit signed values for time_t supports the range 1970-2037), which is plenty of range.

---

There are 86,400 seconds in a day.

Ignoring leap years for a moment (and leap seconds altogether), there are 31,536,000 seconds in a year.

That makes 315,360,000 in a 10 year span.

Add in the three leap days that could occur in a 10 year span and you get: 315,619,200

That number requires 29 bits to represent, so you might as well use a 32 bit representation.

---

I would use an unsigned 32 bit. Write a routine to convert current date/time to seconds since the start time and one to convert seconds to date/time.

Each device can make 0 be the first date/time input into device. Then whenever the date/time is input or output it is massaged using the correct function. The user does not ever know that internally the values are stored as seconds since date/time were set.