Stories
Slash Boxes
Comments

SoylentNews is people

Reducing Year 2038 Problems in curl

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

canopic jug writes:

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.
Reducing Year 2038 Problems in curl | Log In/Create an Account | Top | 25 comments | Search Discussion
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: 2) by darkfeline on Friday February 02 2018, @11:23PM (3 children)

    by darkfeline (1030) on Friday February 02 2018, @11:23PM (#632239) Homepage

    That's like saying, don't hard code the value of pi, what if it changes?

    The Unix Epoch is CONSTANT, otherwise timestamps fail to be, you know, unique.

    --
    Join the SDF Public Access UNIX System today!
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 2) by TheRaven on Monday February 05 2018, @11:34AM (2 children)

    by TheRaven (270) on Monday February 05 2018, @11:34AM (#633237) Journal

    Who cares? The epoc is an arbitrary point in time that lets you use a counter to identify other points in time. Times stored in a filesystem may not use the UNIX epoc, they may use an arbitrary point, as long as they also store that epoc time. Anything sent on the wire is defined by the protocol, not by your OS notion of time. If you're embedding UNIX epoc-relative numbers in your data files then you're either using 64-bit values in which case when you do the local-system-epoc-to-UNIX-epoc conversion you can perform the extension, or you're using 32-bit formats because you don't expect your files to be around after 2038 and if they are then you're screwed anyway.

    --
    sudo mod me up

    • (Score: 2) by darkfeline on Monday February 05 2018, @06:02PM (1 child)

      by darkfeline (1030) on Monday February 05 2018, @06:02PM (#633358) Homepage

      And how are you going to store the epoch time, standardize an epoch epoch time, and store the epoch time as the number of seconds since the epoch epoch? Congratulations, you've just invented a roundabout way of using 64-bit time.

      --
      Join the SDF Public Access UNIX System today!

      • (Score: 2) by TheRaven on Tuesday February 06 2018, @10:40AM

        by TheRaven (270) on Tuesday February 06 2018, @10:40AM (#633726) Journal
        You're missing the point. An integer time value is a fixed offset from some arbitrary time. For interchange you need to agree on a fixed point to use as offsets. For example, most of the Western world agrees on a point about 2018 years ago as time zero for human interaction and measures time from there. On a single program, on a single computer, you need a monotonic counter that increments at a fixed rate per time unit and a way of converting that to and from other calendar systems, whether they're Gregorian or Julian or Buddhist or Islamic calendars, UNIX epoch, the time at which a particular volume was formatted if the filesystem uses timestamps from that time, or whatever. There is no reason that the internal time that is exposed by low-level APIs needs to use the same epoch as everything else. Non-UNIX systems are able to happily use different epoch values internally and interoperate with UNIX systems.
        --
        sudo mod me up