Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Friday February 02 2018, @09:18AM   Printer-friendly
from the I-don't-wget-it dept.

curl is a text-based utility and library for transferring data identified by their URLs. It is now year-2038 safe even on 32-bit systems. Daniel Stenberg, the orginal hacker of curl, has overseen a year-2038 fix for 32-bit systems. Without specific modifications, 32-bit systems cannot handle dates beyond 03:14:07 UTC on 19 January 2038. After that date, the time counter flips over and starts over again at zero, which would be the beginning of the UNIX epoch known as 00:00:00 UTC on 1 January 1970. Given the pervasiveness of 32-bit embedded systems and their long service lives, this is a serious problem and good (essential) to have fixed decades in advance. The OpenBSD project was the first major software project to take steps to avoid potential disaster from 32-bit time and awareness has since started to spread to other key software project such as curl.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Informative) by FatPhil on Friday February 02 2018, @09:32AM (3 children)

    by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Friday February 02 2018, @09:32AM (#631929) Homepage
    > After that date, the time counter flips over and starts over again at zero

    Are you sure it doesn't just become massively negative, and start to represent some date/time in 1901?
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    Starting Score:    1  point
    Moderation   +3  
       Interesting=1, Informative=2, Total=3
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 2) by canopic jug on Friday February 02 2018, @10:01AM (2 children)

    by canopic jug (3949) Subscriber Badge on Friday February 02 2018, @10:01AM (#631935) Journal

    Apparently it depends on the system or package whether the 32-bit value is signed or unsigned. So there is apparently no general solution. But you'll probably want to check with someone knowledgeable or find some other authoritative answer.

    --
    Money is not free speech. Elections should not be auctions.
    • (Score: 0) by Anonymous Coward on Friday February 02 2018, @12:00PM (1 child)

      by Anonymous Coward on Friday February 02 2018, @12:00PM (#631958)

      But the overflow only occurs if the value is signed.

      Also, if you are comparing the values yourself, and assuming it's an application that doesn't need dates before 1970, the fix should be as simple as casting to unsigned before comparing.

      Of course that will cause another overflow problem by 2106. Assuming that there still will be 32-bit systems around at that time.

      • (Score: 0) by Anonymous Coward on Friday February 02 2018, @12:29PM

        by Anonymous Coward on Friday February 02 2018, @12:29PM (#631966)

        All things considered it also depends on what the application uses the date for. Most calls to time functions are to set short term timers (unless the rollover occurs exactly during the lifetime of that timer nothing happens), print a date to screen/a log etc. A rollover would not have any effect on these other than displaying the wrong date in the latter two cases. These kind of things are more an issue if you rely on earlier dates from a database/external timestamp to do tasks.