Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
Per Westermark
09/06/12 12:42
Read: 794 times

#188254 - signed is actually common - to support dates before 1970
Responding to: David Prentice's previous message
David Prentice said:
Your algorithm should cater for 2100 not being a leap year.

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.

A Unix time_t is often a uint32_t. This will wrap to zero in the year 2106.
Any time_t that is implemented with int32_t will go negative in 2038.

Of course most PCs will upgrade their Unix or Linux well before then. And time_t can easily change to an int64_t.

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;

Embedded systems often run for years.
Fortunately, I will have gone up in smoke well before 2106 (or 2038)


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.

List of 22 messages in thread
Error in conversion from Unix EPOCH       Raghunathan      09/05/12 10:03      
   zero        J. Guy      09/05/12 10:32      
   DMonth[month-1] ????        Stefan KAnev      09/05/12 11:50      
      Stefan is correct and...      Daniel Contarino      09/05/12 14:11      
         +4 - 100 + 400      Per Westermark      09/05/12 14:46      
            right, but...      Stefan KAnev      09/05/12 14:54      
               88 years is a long time      Per Westermark      09/05/12 14:55      
                  That is what they said in the 60's      Neil Kurzman      09/06/12 13:46      
      Thanks. Problem solved      Raghunathan      09/05/12 22:26      
         Cross-checking important      Per Westermark      09/06/12 00:10      
            Just a foot note about the year      Per Westermark      09/06/12 03:00      
               ?back conversion      Stefan KAnev      09/06/12 04:56      
                  No - multiplier should not be 366      Per Westermark      09/06/12 05:21      
                     Running out of seconds > 1970      David Prentice      09/06/12 10:00      
                        signed is actually common - to support dates before 1970      Per Westermark      09/06/12 12:42      
                        Will You Now.      Neil Kurzman      09/06/12 13:53      
                           Have you considered leap seconds?      KONSTANTINOS L. ANGELIS      09/07/12 05:00      
                              Leap seconds can almost always be ignored        Per Westermark      09/07/12 05:37      
                                 Time is passing anyway or is it just an illusion?      KONSTANTINOS L. ANGELIS      09/07/12 07:00      
                                    Missiles? Leap seconds contra way larger drift...      Per Westermark      09/07/12 07:45      
         No such thing as a free lunch!      Andy Neil      09/07/12 15:28      
   Link?      Andy Neil      09/08/12 03:16      

Back to Subject List