Post #2991958
2024-07-27 16:26 UTC
Replies (6)
-
@DanadasGrau@mastodon.social 2024-07-27 16:41
@shac@ioc.exchange @skaverat@skaverat.net yeah I was born in 1965, therefore I have no idea why this is an issue.
-
@endrift@social.treehouse.systems 2024-07-27 19:22
@shac@ioc.exchange @skaverat@skaverat.net Unix timestamps can go negative, back to mid-1901. If they couldn't, the 2038 problem would actually be the 2106 problem.
-
@saagar@federated.saagarjha.com 2024-07-27 19:32
@shac@ioc.exchange @skaverat@skaverat.net I can imagine a tech startup of zoomers forgetting this
-
@danmcd@hostux.social 2024-07-27 23:02
@shac@ioc.exchange @skaverat@skaverat.net You do know time_t is signed, right?
-
@nik@toot.teckids.org 2024-07-28 14:04
@shac@ioc.exchange @skaverat@skaverat.net That reply doesn't make any sense. To begin with, the concept of UNIX time is simply "seconds relative to 1970-01-01 00:00:00 UTC". It does not dictate any specific encoding. time_t on current systems is a 32-bit *signed* integer. UNIX timestamps (encoded as 32-bit time_t) go back to 1902.
-
@mirabilos@toot.mirbsd.org 2024-07-28 14:15
@shac@ioc.exchange @skaverat@skaverat.net uhm… time_t is allowed to be signed (or even float), and it is signed in common Unicēs, so… … I fear for the kernel you’re allowed to be engineer on.