Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2038: Only 21 years away

lwn.net

Post reply on HN
Print view View original

321–330 of 333 posts

Re: 2038: Only 21 years away

#321

Post by aaronmdjones »

ekimekim wrote: post #267
gbrown_ wrote: post #27

> statx() will serve as the year-2038-capable version of the stat() family of calls Does this seem horrible to anyone else? Why not fix stat()? Does this syscall have to be so highly preserved even when it will be broken? One of the advantages of the OpenBSD approach of being able to make intrusive changes saw their time_t made 64-bit in the 5.5 release in 2014. https://www.openbsd.org/55.html Admittedly this is much…

Slightly off topic, but...why "x"? I thought the normal procedure for something like this would be "stat2()" (eg. accept4())

accept4() is so-named because it takes 4 arguments (instead of the usual 3). The x here probably means extended; statx(2) doesn't take any more arguments than stat(2).

Re: 2038: Only 21 years away

#323

Post by tyingq »

pbhjpbhj wrote: post #306
tormeh wrote: post #181

Earlier quoted context omitted.

>experience with humans So true. That said, thinking 38 years into the future is usually not sensible for most businesses, because it's very possible that they're bankrupt before then. Thinking 21 years into the future also offers poor ROI for the same reason.

I was thinking large companies, banks etc.. I'm not in IT/programming but remember (despite being young) that 2 other calendar related 'bugs' were mentioned at the time. IIRC we've had one and the epoch bug is the second. Strikes me that big businesses would have thought "will we need to do this again in a few years" and acted appropriately and that there should be a trickle down effect as large corps demand future p…

Generally, the bigger and older the company is, the more unmaintained cruft you have. Banks would be one of the worst I imagine.

Re: 2038: Only 21 years away

#324

Post by clock_tower »

valuearb wrote: post #320
contingencies wrote: post #258

Earlier quoted context omitted.

There was almost certainly some forms of relatively advanced seafaring 8000 years ago possibly including skin boats, sails and paddles, ropes, sealants and astronomy. Also, fairly sophisticated metallurgy was widespread with at least silver/iron/gold, possibly bronze. Writing was known to some cultures. Horses, camels and water buffalo were likely all domesticated. Use of drying/smoking for preservation and curing of…

I can believe seafaring, astronomy, and metallurgy. But yogurt? Now you're just pulling my chain.

I don't know how much you know about yogurt, so I apologize in advance if this sounds condescending; but yogurt has been eaten since at least the 5000s BC, and is easy to produce, probably even by accident. It's obtained by controlled souring of unpasteurized milk; clabber, which is almost too sour to be edible but is safe to eat if you can stand the taste, comes from spontaneous souring.

Fernand Braudel (in The Structures of Everyday Life) talks of how it was the staple food of the poor in Turkey, and I think in Persia. US commercial yogurt is weak and sugary; the Eastern variety is much more lifelike.

Re: 2038: Only 21 years away

#325

Post by fgandiya »

Speaking of the 2038 bug, I'm impressed with Paul Ryan's rhetoric [0]

“I asked CBO to run the model going out and they told me that their computer simulation crashes in 2037 because CBO can’t conceive of any way in which the economy can continue past the year 2037 because of debt burdens,” said Ryan.

I love politicians.

[0]-http://www.cnsnews.com/news/article/ryan-debt-track-hit-800-...

Re: 2038: Only 21 years away

#326

Post by mcbits »

Sean1708 wrote: post #312
mcbits wrote: post #301

Earlier quoted context omitted.

64 bits only cover about 7 months at picosecond resolution, so it's possible that 64 bit timestamps will be too small sometime this century, depending on how tightly synchronized the world becomes. An extensible timestamp might not be a bad idea and could still be kept under 64 bits for currently practical purposes.

For picosecond resolution to be useful wouldn't clock rates need to be on the order of THz? Otherwise what advantages would ps resolution give you over ns?

Bulk data processing clock speeds could still be lower, but some devices may need THz timing, for example to align and integrate data from a swarm of sensors in motion relative to each other. Imagine trillions of 1-pixel cameras that know exactly when, where, and in which direction each pixel was captured (but not necessarily capturing literal image data).

Re: 2038: Only 21 years away

#327

Post by kbp »

MHordecki wrote: post #261
sedachv wrote: post #247

Earlier quoted context omitted.

That is actually how Common Lisp represents time: https://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Bo... When you look up "integer": https://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Bo... "An integer is a mathematical integer. There is no limit on the magnitude of an integer." What happens when an integer overflows from a fixnum (single-word representation) is that it gets upgraded to a bignum behin…

Python supports arbitrary-width integers too. Its datetime implementation, however, is implemented partially in C, and does not support arbitrary timestamps.

Lisp's support for numbers goes beyond automatic bignum promotion, for example (/ 1 3) gives the rational 1/3 instead of an approximation, and (sqrt -1) gives #C(0.0 1.0), that is, 0 + 1i.

Re: 2038: Only 21 years away

#329

Post by madphrodite »

astrodust wrote: post #279
HankB99 wrote: post #223

Earlier quoted context omitted.

Yeah. I was working on an IoT system that uses NTP to set time. I generally plan a 20 year life span for tings like this. There's S/W I wrote over 20 years ago that is in devices still in use. The only good thing about this is that I'll not likely be around when trouble crops up. I didn't see any way to accommodate changes that are nearly decades away in code I write today.

Once in a while you'll stumble upon a Novell Netware server that's been running since the mid 1990s. Twenty years isn't a long time.

Novell 3.x or 4. IPX/SPX only. print, file and directory service. Netware client for windows. Man I loved those days.

Re: 2038: Only 21 years away

#330

Post by madphrodite »

cbr wrote: post #34
mrkgnao wrote: post #32

> BSD-based distributions have the advantage of being able to rebuild everything from scratch, so they do not need to maintain user-space ABI compatibility in the same way. I don't understand, not knowing much about BSD. Is this an LTS/support thing? Can someone explain?

Generally people build BSD packages from source instead of installing binaries. (I think; I've not used BSD.)

I've used both, most bsd users have. Prefer packages but ports is useful for custom builds and desktop systems.
Post reply on HN