Many embedded systems are designed to accurately log data and perform other time keeping functions. Although it is possible to store each character from the time and date fields, time is usually represented by a single variable. The data and time information are encoded in the bits stored by the variable, allowing compact representation of the time. For example, a variable can hold the number of seconds elapsed since the year 2000.
This is the approach taken by practically all of real time libraries you’ll come into use in microcontrollers, microprocessors, and even PCs. Standard C libraries uses a variable, oftentimes defined of the type time_t, and increments it by a certain amount. Representing time accurately means taking into account leap years and other events. Higher resolution implementations can, for example, count the number of nanoseconds since a certain moment in time.
Like everything else in engineering, the size of the variable used, the accuracy, and the time range that can be represented are all on opposite sides of a triangle. More accuracy will reduce the range of time that can be represented, unless a larger variable is used.
Unix time starts at 00:00:00 January 1st, 1970, and its time library uses a signed 32-bit number to represent time as the number of seconds elapsed from the date. Because it uses a signed variable, the variable itself can represent both time before January 1st, 1970 and time after.
The variable can represent numbers from -2147483648 to 2147483647. When converted to time, this ends up representing 136 years, and in the case of Unix it can represent time from December 12th, 1091 to January 19th, 2038
We are only 24 years away from 2038 where systems will go back in time. Like everything, nipping it in the bud early means the lower the cost of dealing with it later.
Unix is not alone. When reviewing the standard library of several embedded processors such as the MSP430, we found that it used a 32-bit unsigned representation beginning in 1900. This allows it to represent time until 2036, only 22 years away.
If you’re doing product development with embedded systems and need to represent time using the standard library that comes with your compiler you should sit down and understand the epoch and the range. If it meets your requirements then move on, as I can expect for many of you. For the rest, there are it depends on the particular application.
If the standard library you use for your device supports larger data types for representing time, then use it. Otherwise, you will need to implement time handling using larger data type.
While doing this on a powerful microprocessor might be relatively painless, a small embedded system might require a more custom approach. 4 extra bytes can easily eat up memory. For example, if logging the time of every entry is needed, then 4 bytes will increase linearly with every entry. One solution is to create a custom implementation that uses only 5 bytes. The range will increase sufficiently but storage is still optimized.