| ??? 09/06/12 16:00 Read: times |
#188253 - Running out of seconds > 1970 Responding to: ???'s previous message |
Your algorithm should cater for 2100 not being a leap year.
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. Embedded systems often run for years. Fortunately, I will have gone up in smoke well before 2106 (or 2038) David. |
| Topic | Author | Date |
| Error in conversion from Unix EPOCH | 01/01/70 00:00 | |
| zero | 01/01/70 00:00 | |
| DMonth[month-1] ???? | 01/01/70 00:00 | |
| Stefan is correct and... | 01/01/70 00:00 | |
| +4 - 100 + 400 | 01/01/70 00:00 | |
| right, but... | 01/01/70 00:00 | |
| 88 years is a long time | 01/01/70 00:00 | |
| That is what they said in the 60's | 01/01/70 00:00 | |
| Thanks. Problem solved | 01/01/70 00:00 | |
| Cross-checking important | 01/01/70 00:00 | |
| Just a foot note about the year | 01/01/70 00:00 | |
| ?back conversion | 01/01/70 00:00 | |
| No - multiplier should not be 366 | 01/01/70 00:00 | |
| Running out of seconds > 1970 | 01/01/70 00:00 | |
| signed is actually common - to support dates before 1970 | 01/01/70 00:00 | |
| Will You Now. | 01/01/70 00:00 | |
| Have you considered leap seconds? | 01/01/70 00:00 | |
| Leap seconds can almost always be ignored | 01/01/70 00:00 | |
| Time is passing anyway or is it just an illusion? | 01/01/70 00:00 | |
| Missiles? Leap seconds contra way larger drift... | 01/01/70 00:00 | |
| No such thing as a free lunch! | 01/01/70 00:00 | |
Link? | 01/01/70 00:00 |