SoylentNews is people
SoylentNews
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.
(Score: 2) by HiThere on Friday February 02 2018, @06:50PM (7 children)
I have a suspicion that the work is unnecessary, as most things will be changed within two decades.
OTOH, it's something that *ought* to be done properly anyway. The question is "What does properly mean?" and that's extremely use-case dependent. For some purposes using even an extra byte is a mistake...but those cases won't be running POSIX anyway. But you clearly shouldn't use a date for a short timer. And signed numbers in times are generally a bad idea...but not always.
The suggestion about depending on gmtime and friends function is wrong, because one often needs time expressed as a number. Sometime an integer is required, but often a float is better. I'd say that the time should be in seconds past the epoch as a double, and this should give sufficient resolution (often spuriously exact) on most systems. Unfortunately, this means the further you get from the epoch, the less exact the time is.
There probably *isn't* a universally good answer. For my purposes the floating number of seconds (not even double) since the epoch would suffice quite well, but others have other needs. My best guess at the answer is to have the epoch be defined by a global variable signed 32 bit integer as the number of years since, oh, January 1st, 1970, and time defined as a system default integer number of microseconds since the epoch. That should handle all the common cases. and have a second time defined as a 64 bit float number of seconds since the epoch as defined by the system. (I'd specify a 128 bit float, but 64 bits is more accurate than the current clocks already.) This would give you minimal overhead, and allow the epoch to be easily updated in case of need.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by AthanasiusKircher on Friday February 02 2018, @07:39PM (1 child)
While "most things" is likely true, lots of basic embedded code in OSes and such will likely still be around.
No offense intended, but this was precisely the attitude that created the Y2K "bug," which ended up costing hundreds of billions of dollars as old programmers expert in dead computer languages were pulled out of retirement to fix things... things that no one expected to still be around a couple decades after the code was first written.
(Note: there are those who claim a lot of Y2K prep was unnecessary and that the potential critical failures were overestimated. One can probably argue that there was a bit of overkill beyond major critical systems. But clearly there still was a lot of minor old code that was still in use and would have needed patching eventually... even if it wouldn't have resulted in a catastrophic failure on January 1st, 2000.)
(Score: 2) by HiThere on Saturday February 03 2018, @02:00AM
The thing is we've been (slowly) working on the problem ever since before the 64 bit chips became common. Places where it is critical should already have been patched. And for places where it's not critical....up until last year I still had a MSWindows95 system running. It was annoying that I couldn't set the time, but it sure wasn't important.
And since it's still two decades off, there shouldn't be any need for more than normal updates to software. (Of course you can say that some applications won't update their software, but they won't be helped by this kind of thing anyway.)
I remember that people started talking about how to address the 2038 problem back in the 1990's. So anything critical that people are willing to fix should already be fixed, and for the rest we're going to be forced to depend on obsolescence. Just make sure that any new software or updates to old software handles it properly. And that should be basic routine, not anything special.
I.O.W. if there's a new update to curl, and *that* is the main feature, then I don't see the reason for it. It should be built into the next standard update, the next standard release, whatever.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Insightful) by darkfeline on Friday February 02 2018, @11:35PM (1 child)
The "proper" fix is to use a 64 bit signed int, which gives you more resolution than you can even measure on a quartz clocked CPU (nanoseconds or picoseconds) and more bits than needed to represent the entire lifetime of the universe, from Big Bang to heat death.
Join the SDF Public Access UNIX System today!
(Score: 2) by HiThere on Saturday February 03 2018, @01:43AM
But for some systems that's using an extra 32 bits every time you invoke the time. Which is why I used two standards. The 64 bit int of nanoseconds would be a reasonable replacement for the 64 bit float I suggested as the second form, and you can argue quite reasonably that it shouldn't have a flexible epoch, but there also needs to be a more compact form.
Actually, there need to be several standard forms, but they could all be based off of one of the other two bases. Sometimes what you need is a 16 bit time with a step size of 30 seconds. Usually memory isn't so tight that it really matters, but sometimes it does, and it's good to have well defined standards to drop into place. Float times have the advantage that different precisions of clock can each give all the precision they have available. etc. Of course you can do that with an int, too, but integers carry a false implication of total precision.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by TheRaven on Monday February 05 2018, @11:43AM (2 children)
I presume that's addressed to me, but it implies that you didn't actually read my post. You use gmtime when you want a time that is relative to something specific. You use an epoc-relative time when you want some numbers that you can compare, but if you actually care when the epoc zero time was then you are doing it wrong.
Sounds unlikely. A 32-bit floating point value has a 24-bit mantissa. If you're only counting seconds, then that gives you a range of 194 days. If you count milliseconds, it gives you a range of 4 days.
OpenStep uses a double for NSTimeValue, which gives you around 285 million years at second precision, 285 thousand years at milisecond precision, 285 years at microsecond precision, and about 100 hours at nanosecond precision.
If you want two epochs, why not have a 64-bit one defined at a fixed point and a 32-bit one defined as system boot time (UNIX actually does define a since system boot timer already)? For most uses, the 32-bit one is fine. It will handle uptimes of a few decades (unlikely, even for VMs)
sudo mod me up
(Score: 2) by HiThere on Monday February 05 2018, @06:11PM (1 child)
OK, that's less coverage than I had supposed. But it would still work for my current purposes.
System boot time would work for some purposes, but not for any that had to be persistent. I don't really want two epochs, but for different purposes I want an accurate timer that can be relied on to be approximately identical (nearly monotonic) across machines, and I also want a compact time. It would be really nice if you could combine them into one time, but the requirements conflict. The long time epoch is so that different machines in different places will agree on what time it is, and the compact time epoch is so that you can refer to times in the "recent" past and future without having overflows. Boot time can make it difficult to refer to things that happened last year...or even two hours ago.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by TheRaven on Tuesday February 06 2018, @10:35AM
sudo mod me up