The Picard Maneuver@lemmy.worldM to memes@lemmy.world · 4 months agoWe're being short-sightedlemmy.worldimagemessage-square14fedilinkarrow-up10
arrow-up10imageWe're being short-sightedlemmy.worldThe Picard Maneuver@lemmy.worldM to memes@lemmy.world · 4 months agomessage-square14fedilink
minus-squareRusty@lemmy.calinkfedilinkEnglisharrow-up1·4 months agoI don’t think 10000 year is a problem. There is a real “year 2038 problem” that affects system storing unix time in signed int32, but it’s mostly solved already. The next problem will be in year 33000 or something like that.
minus-squaregnutrino@programming.devlinkfedilinkEnglisharrow-up1·4 months agoThere are so many problems there is an entire Wikipedia page dedicated to them.
minus-squareGissaMittJobb@lemmy.mllinkfedilinkarrow-up0·4 months agoIt’s going to be significantly more than the year 33000 before we run out of 64-bit epoch timestamps. The max value for signed 64-but epoch values is more than 292 billion years away, or 20 times the age of the universe itself. So yeah, we’re basically solid forever with 64-bit
minus-squarefrezik@midwest.sociallinkfedilinkarrow-up1·edit-24 months ago33,000 would come from other programs that store the year as a 16-bit signed int. Year 32,768, to be precise.
I don’t think 10000 year is a problem. There is a real “year 2038 problem” that affects system storing unix time in signed int32, but it’s mostly solved already. The next problem will be in year 33000 or something like that.
There are so many problems there is an entire Wikipedia page dedicated to them.
It’s going to be significantly more than the year 33000 before we run out of 64-bit epoch timestamps.
The max value for signed 64-but epoch values is more than 292 billion years away, or 20 times the age of the universe itself.
So yeah, we’re basically solid forever with 64-bit
33,000 would come from other programs that store the year as a 16-bit signed int. Year 32,768, to be precise.