Are we still calling it Y2k38? I think it needs some rebranding or we won’t be able recruit devs to put in the overtime to fix it so history can decide it was all fake.
Epoch fail!!!
Submitted 1 year ago by LodeMike@lemmy.today to [deleted]
https://lemmy.today/pictrs/image/c267199f-b9ea-4131-9fe5-91d95ab78302.jpeg
Comments
Bishma@discuss.tchncs.de 1 year ago
NegativeInf@lemmy.world 1 year ago
I tend to favor The Epochalypse.
TexasDrunk@lemmy.world 1 year ago
Well you won. I’m headed in to work tomorrow to get started on marketing it to the C suite using this.
blackluster117@possumpat.io 1 year ago
Damn, that is catchy.
jaybone@lemmy.world 1 year ago
I’ll just wait for Crowdstrike to deploy a fix.
ChaoticNeutralCzech@feddit.org 1 year ago
Inaccurate. Signed 32-bit integer epoch overflows from January 2038 to December 1901.
saigot@lemmy.ca 1 year ago
If the calendar was written in C++ or many of it’s derivatives then signed integer overflow is undefined behaviour and it could technically choose to do anything it damn well wants (unsigned integers actually do have defined overflow behaviour). Something tells me the runtime of a paper calendar is anything but standard :D
Zoomboingding@lemmy.world 1 year ago
It’s not the overflow that’s the issue, but a calculation failure that causes the date value to be “0” and thus list the date as January 1, 1970. It’s happened to me several times with Pokemon GO.
jaybone@lemmy.world 1 year ago
Fuck the specs. If Pokemon GO says it, that’s good enough for me.
ChaoticNeutralCzech@feddit.org 1 year ago
In this case, it’s the overflow as
01111111…11111111+1
in binary becomes10000000…00000000
.Image
But yes, some programs erroneously fall back to
0
in case of anull
value, which corresponds to 1970-01-01. That’s why so many geotags exist for Null Island.observantTrapezium@lemmy.ca 1 year ago
Haha, that’s right. Immediate noticed that.