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

261–270 of 333 posts

Re: 2038: Only 21 years away

#261

Post by MHordecki »

sedachv wrote: post #247
antirez wrote: post #24

Using a 64 bit timestamp will only move the problem 292 million years forward, so probably the best solution is to use a variable length field.

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.

Re: 2038: Only 21 years away

#262

Post by bnj »

nsxwolf wrote: post #120
AlexC04 wrote: post #44

Earlier quoted context omitted.

I hope you've trademarked the term "epochalypse" because it is really catchy! I love it.

I will be just 5 years away from retirement, so I will use this as an opportunity to shore up my 401k. Of course, the singularity will be here by then and fix it for us just before turning us all into paper clips, yada yada. I will advertise with the slogan "Epochalypse... NOW."

Make sure your 401k is the first thing you certify as 2038 compliant

Re: 2038: Only 21 years away

#264

Post by ekimekim »

antirez wrote: post #217
antirez wrote: post #24

Using a 64 bit timestamp will only move the problem 292 million years forward, so probably the best solution is to use a variable length field.

Pardon, it's billion indeed if you count seconds. I wrote millions for mistake, but thinking about it once you have 64 bits, milliseconds are nice to have...

But once you have milliseconds, microseconds are nice to have...

The linux kernel (and many other applications) solve this with a tuple of 64-bit ints (seconds, nanoseconds) where 0 Other systems still (perhaps most commonly) are using double floats for seconds. Under that scheme, nanoseconds were only representable until Feb 17th 1970. The last representable microsecond will be some time in 2106, and the last representable second won't be for another 150 million years or so.

Personally, I'm happy with the precision afforded by floats. Timing uncertainly (outside niche applications) is generally much larger than a single nanosecond, and even microseconds are a bit suspect.

Re: 2038: Only 21 years away

#265

Post by jbooth »

narrator wrote: post #163
DannyB2 wrote: post #155

Earlier quoted context omitted.

My retirement planning is to work on the Y10K problem. When the year 9997 comes along, everyone is going to start worrying about the rollover to five digit years. In about the year 9995 I will start seriously brushing up on my COBOL.

Yes, I know some of us will never retire. 8000 years in the future career planning is an interesting thing to think of though. 8000 years ago the only thing that was going on was some neolithic agriculture. Domestication of the Jungle Fowl (modern day chicken) in India and the beginning of irrigated agriculture in Sumeria were probably the biggest news items of that millennium. I guess someone from 8000 years ago cou…

Without artificial fertilizer but I recall reading that they massively improved yields from 1000-1500, let alone a span of 4000 years.

Why make "artificial fertilizer" a goalpost? Yield is what matters, there's apparently a million things that go into improving rice paddy yields.

Re: 2038: Only 21 years away

#266

Post by wolfgang42 »

janwillemb wrote: post #95
axlee wrote: post #78

Earlier quoted context omitted.

It was a good time to be a COBOL developer.

I never quite understood why the transition from 1999-2000 should be a big deal for a computer system, until I learned about how COBOL works: it stores numbers as its string-representation unless told otherwise, and trying to store 100 in a field of two bytes will happily be stored as "00". Of course we had other bugs, with the same cause, well after the y2k-period.

I work with a database that has its origins in the COBOL era. All of the date fields are specified in the copybooks as four PIC 99 (i.e. two decimal digits) subfields, CCYYMMDD. This separation of CC and YY surprised me until I realized that it allowed them to add Y2K support by setting the default for CC to '19' and switching it later.

Re: 2038: Only 21 years away

#267

Post by ekimekim »

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())

Re: 2038: Only 21 years away

#268

Post by wolfgang42 »

joepvd wrote: post #242
5ilv3r wrote: post #233

Earlier quoted context omitted.

This is a great point. Time synchronization between systems that do not share a clock line is a pretty recent thing. It didn't used to matter at all if your clock was wrong, and many people would never notice or bother to fix it. Now if your clock is wrong you can't even load anything in a web browser. Your clock sync daemon has to fix your clock before the certs will be accepted as valid. HTTPS is a bummer, maaan.

You have a reference for HTTPS problems with skewed client time?

Not OP, but the obvious issue is that with very large offsets the certificates all look like they've either expired or are future dated; either way they're not accepted. I had a laptop with a dead clock battery for a while; I would sometimes fumble the time when booting it and would discover the mistake when I couldn't load my webmail or Google. (Also, the filesystem would fsck itself because it was marked as last fscked either in the future or the far past, but I didn't always notice that.)

Re: 2038: Only 21 years away

#269

Post by ekimekim »

sixdimensional wrote: post #220

On a side but related note, I don't understand why many programming languages and databases don't have a positive and negative infinity date placeholder/token value that is standardized and cross platform. Negative infinity date is "past", positive infinity date is "future". This would solve the common problem of what date to use when you are trying to talk about unknown date in the future or unknown date in the past…

In languages where epoch time is generally represented as float, inf and -inf do what you describe.

Re: 2038: Only 21 years away

#270

Post by hinkley »

archgrove wrote: post #9
Aloha wrote: post #7

Earlier quoted context omitted.

There is a certain amount of snark embedded in this post, but its not a bad idea at all - I'll be in much the same boat at that time - perhaps I can borrow the same idea...

It wasn't intended to be sarcastic. I suspect there will be a lot of businesses (especially finance) interested in verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. I lived through the Year 2000, and watched the same thing happen there. With suitable groundwork, there will be a willing and wealthy market looking for people to assuage their fears - a service I see…

Woah, you were alive in the year 2000? Tell us what that was like, grandpa!
Post reply on HN