In an embedded device, it may be decided that it isn't needed to span the year 2100. So then the 1/100 and 1/400 rules can be stripped out saving code space.



time_t is normally int32_t - not uint32_t - to cater to dates before 1970. The language standard says that the type and precision is implementation-specific, but lots of people happens to be born before 1970, giving a need for functioning date functions before 1970. The computer world is likely to move to 64-bit numbers en masse before 2038. But for special applications, the data type can be made unsigned or long long. Or if ignoring the language standard, the base date could be set differently than 1970-01-01.

32-bit Debian 4 (yes old): #define __TIME_T_TYPE __SLONGWORD_TYPE
64-bit Debian 6: #define __TIME_T_TYPE __SLONGWORD_TYPE
M$ Visual C++ 6 (I think): typedef long time_t;
MinGW: typedef long time_t;


With a signed 32-bit integer the algorithm don't need -1/100 to handle year 1900 because it can't reach as far back. And it can't reach all the way to year 2100. And without the -1/100 term, there is no need for the +1/400 term to correctly treat year 2000 as a leap year.

But embedded systems need not follow any ANSI standard for CRTL etc - the developer should know exactly what the needs are. So it would be possible to either switch to a larger data type to span a wider time range, or make time_t unsigned to gain 68 more years into the future but at the cost of not being able to process dates before 1970. An embedded system could even change the epoch from 1970-01-01 midnight to some other date, that better brackets the date range support needed.

But in the end - for a "standard" 32-bit unix machine, there is no need for -1/100 and +1/400. And a huge percentage of embedded devices built today will be dead before year 2038. And people who want to, can very easily adjust the code to span 68 years further ahead with unsigned. Even further ahead with changed base year or 64-bit time stamps.