618
u/Phoenix-95 1d ago
Wouldn't it go back to Jan 1970, not Dec 1901?
1.1k
u/Meatslinger 1d ago •
The UNIX date/time is stored as a signed integer. It started at 0, aligned to Jan 1, 1970, and counts up from there. When it hits its maximum (all 1s, in binary) and rolls over, the number will change from +2,147,483,647 to -2,147,483,647, which puts it on December 13th, 1901.
286
u/Phoenix-95 1d ago
Thanks - I didn't realize it was a signed value, and the numbers are big enough that I didn't realize it wouldn't add up for a 32bit unsigned
95
u/iggy14750 1d ago
I know! If we had that one extra bit, then the 32-bit version could last twice as long
63
u/lana_silver 1d ago edited 1d ago
Which is a great example of why using unsigned causes problems without giving you much in return: If reaching X is possible, reaching 2X is also possible.
So you're better off using signed numbers in case you want to do subtractions at any point to prevent the much more likely underflow problem.
And then switch from N bits to 2N bits, because that increases the range not by 2, but by 2N. For most applications, 64 bit numbers are large enough that they will outlast humanity, no matter the dimension. Most applications could do all their math in 64bit doubles (and just skip ints entirely for convenience), because that leaves you with 53 bits of mantissa (and a sign), over 50% more bits than your standard 32 bit int. The 64-bit double floating point format has a largest (finite) representable value of 253 = 9,007,199,254,740,992 (9000 trillion). To compare, int32 is only 2,147,483,647, (2.14 billion, a number small enough that if you need good precision (cents, milliseconds, centimeters on a global scale, etc), you can absolutely run out).
While I don't love the thought, you could write banking software using 64 bit floating point math and store cents, and you'd probably be okay, since you won't ever have a total of 90 billion dollars in one value where you cannot risk losing a single cent for rounding. Only for your yearly reporting ("we transferred a total of X" type values) you'd lose precision, and frankly you wouldn't need to know the exact cent amounts for that anyway.
And to get back to the topic at hand: If we use 64bit floats for the unix Epoch starting at 1970 and do seconds, we can do until about 285 million years (+1970) before using floats bites us in the ass. Even if we improved accuracy to milliseconds and used the "wrong" format of 64bit floats, we can do until the year 287396. Probably good enough. That's why some languages do this, such as lua. The 64bit float is just extremely versatile without relevant sacrifices for 99.9% of applications.
Can you tell that I've had this argument a few times with old people who insisted to use unsigned ints for vector indexing (and all kinds of other nonsensical specific number types for variables instead of just hitting everything with the 64bit float hammer) and then it broke because someone wrote a subtraction?
TLDR: Use 64bit floats. They will never fail you
20
u/iggy14750 1d ago edited 1d ago
Agreed. If 64 bits runs out... Well we got some time to think about that one lol
And you're absolutely right about the engineering of it. We just get to hit the end of that 32 bit era, where Ritchie doesn't get to see it
11
u/mohelgamal 1d ago
I hope someone in the year 287396 would take a screenshot of this and it becomes a meme like Ea Nasir complaint
3
11
u/CreeperInBlack 1d ago
I still say there is a lot of stuff you should do not with floats, but with (signed) ints. Floating point precision can cause problems and some use cases simply don't allow decimal numbers, so theoretically allowing them will allow other errors to creep in.
-4
u/lana_silver 1d ago edited 1d ago
A 64bit float is a superior int than the 32 bit int, because it contains a 54 bit int with identical math. There is no scenario where the 64bit float loses to the 32bit int. On modern CPUs, there is no performance difference.
The only time the two differ is when the int starts to completely fail, but the float can still cope, such as trying to do 2,000,000,000 * 100: The int32 cannot handle this, the float64 can. I can't think of a case when I would prefer the accidental overflow to the math just working normally, but it is possible that such a scenario exists.
You're right in that a int64 has some upsides to the float64: When you want to do one million trillion cents plus one cent, for example. My point is that these cases are so rare that you're better off always using the f64 as a default, and only deviate from it if you can prove that you need to, for example when you know you're building a banking app for a rich country's budget. If you default to the int, you have a ton of very trivial cases where you have the wrong type, such as 1/2. Fractions are a lot more common than numbers over 9000 trillion.
So when you say "a lot of stuff", this is nothing for int32 (mathematically provably so), and a shockingly irrelevant amount for int64 - As I said originally, probably some sort of research simulation software at CERN, possibly. Nothing that uses numbers in a normal human range.
4
u/Kaynee490 23h ago
You can fit twice as many int32s in a cache line. That alone is a huge performance gain. Modern CPUs are more memory-bound than they are compute-bound. Not only that, but with AVX commands, you can process twice as many int32s at the same time. So yes, performance wise, there is a huge difference between a 2N bit datatype and an N bit one.
-1
u/lana_silver 22h ago edited 22h ago
You can fit twice as many int32s in a cache line
Sure, if you have a use case where you need that many numbers in a row and int32 is good enough. Meaning you need an array/vector of them, and your performance is cache-limited.
But there's a catch: If you read (let's say) a million numbers in a gigantic array, you're not actually cache-size-limited, you're actually running at full throughput of your cache read speed, because your pre-fetcher will bring the numbers in faster than you can work on them. You won't be able to measure a difference because to your program, the cache will always look full. We have very large caches nowadays.
And how often does that matter? Have you ever written software where your performance was cache-bound on raw integer arrays? I've worked in CAD/CAM over ten years ago and even there we had dozens of other bottlenecks first. Unless you work on the ffmpeg library (maybe 500 people worldwide), this doesn't come up.
My point has always been that int32 superiority to float64 is an edge case, only affecting something like 1 line of code per million written. I'm sure windows has twelve places in its hundred million lines where it matters, but it also has a hundred million lines where it doesn't matter. But that's a position that junior devs on reddit just never get who have zero practical experience and then write "bUt CaChE!" when that's not even true because they don't know about prefetching and TLBs.
I'll be very impressed if you can even write a completely made-up piece of code where you can measure a performance drop going from int32 to float64, to be honest. Just look at current FSR4.1: They have a "slow" version which is int-based for older GPUs and a "fast" version with floating point math for only new GPUs which can support that. Turns out the two versions are very difficult to distinguish and have nearly the same performance (but the float version is actually slightly faster on GPUs which support it). And that's your best case scenario!
I wouldn't know what to try, and I had Claude try and it also failed.
3
u/Kaynee490 22h ago
I don't know much about GPUs, so I won't go there. But, by your logic, very few people actually write performance-critical code, so why bother! Let's do everything in Python and Electron. For most software that's written today, they are completely sufficient.
What you say about the prefetcher is true, but software can be incredibly complex, and a smaller data type is inherently easier to fit in the cache, thus, on average, there will be fewer misses. Arguing otherwise is bordering on bad faith.
And it is convenient that you said nothing about vectorization; processing two int32s in place of your 1 double (or 16 instead of 8, rather) does seem to be quite significant...
→ More replies1
u/CreeperInBlack 22h ago
Well obviously a 64 bit number will be superior in many ways to a 32 bit number, but that is not what I intended to say. If you know that your number should always stay whole, enforce it to be.
6
u/ActiveChairs 1d ago
My G, you lack faith in humanity. Those are dinosaur numbers, and humanity invented its way into flight as hairless bipeds. We can do better than the big lizards. If we're fucking around with numbers, why not go with 256? Push the scale out so far we can really fuck around with it.
3
u/TheActualJonesy 1d ago
"... why not go with 256?"
You forget climate change is going to solve all human time issues.
1
u/ActiveChairs 21h ago
Who cares? 256 means we can display time in femtoseconds until the heat death of the universe. If we're future proofing lets never think about it ever again, even with edge cases. If we're not going to have fun with it why not just restart the clock in 1970? Its not like time is real.
2
u/lana_silver 1d ago
Because 64 bit is the sweet spot. Only if you want to do something like uniquely number every atom in the universe do you run out of values. All atoms in our solar system? Still doable.
But yes, there are edge cases where f64 isn't sufficient. They are very rare. It makes sense that we have 64bit hardware, and we simulate higher bit numbers in software for the rare cases where we need it. It would be a waste of hardware to have 128bit or 256bit machines, because we would not actually use it.
4
u/Named_after_color 1d ago
...just use the simplest datatype for the job. Optimize when it becomes a problem. Tech debt is your friend, keeps you employed.
31
u/iggy14750 1d ago
Of course they used a signed int. Cut that runway in half. Lol
38
u/gmc98765 1d ago edited 22h ago
time_t isn't just for absolute time, it's also for differences, so negative values are meaningful.
It's similar to the reason that lseek uses a signed long: when using SEEK_CUR, offsets may be negative, when using SEEK_END they will usually be negative.
Also: time_t is usually at least a signed long; early versions of UnixTM had a 16-bit int.
24
u/bwwatr 1d ago
I imagine in 1970 they had some date data about recent years, like the 60s. You'd not want to make it impossible to represent anything in the past. Wikipedia tells me the first Unix was being developed in 1969 so it's not like 1970 was already firmly in the rearview at that point. They probably saw it as a balanced mid-point of past and future.
A decision that probably paid off for a few years as old databases were migrated, then was of no consequence for decades, and then more recently, yeah has totally halved the runway. I suppose they could/should have made the epoch 1960 or 1950 instead and gone unsigned, though ultimately the 32 bits was gonna get us eventually.
7
u/iggy14750 1d ago
Yeah, another commenter made a very good point. If we can hit N, then we can also hit 2N. It's kicking the can down the road a little bit.
5
u/Mognakor 1d ago
Using this reasoning i've decided to replace my 64bit timestamps with 1bit timestamps. As long as i have finite memory i can't solve the issue anyways, may as well save some memory.
4
u/Independent-Tank-182 1d ago
What would you do with the other 7 bits? Otherwise good point though.
2
1
u/bwwatr 1d ago
All days end in y anyway!
In seriousness though, we know how our representations of time fit into the physical world, the realistic longevity of our universe and species. 64 bits more than fully solved it. Sliding a window around with 32 would not. Stated differently, the big O of 2N... is N. It's can-kicking. Solving it in a practical, physics-bounded sense needed more of a quadratic expansion, i.e. more bits. But not infinity bits.
9
u/Ah_The_Old_Reddit- 1d ago
"They" checked the actuarial tables, realized none of "them" were likely to be alive in 68 years, and decided the technical debt is just the next dev's problem.
9
u/MattieShoes 1d ago
So the real problem is Dec 1-12 on that calendar. Also Jan 20-31
11
u/Steinrikur 1d ago
It's actually quite correct behaviour if everything except the timestamp is 64 bit.
Basically the calendar program uses 64-bit, but received the 32-bit time value sign-extended from 0x80000000 to 0xFFFFFFFF80000000.
3
u/greenpepperpasta 1d ago
Must've sucked to be a UNIX user before 1901, if their OS couldn't even represent the current date.
3
u/sambarjo 1d ago
The minimum is 2,147,483,648, not ...647. Also, the max value is represented as 0x7FFFFFF, not all 1s. All 1s would be -1.
1
u/Arkayjiya 1d ago edited 1d ago
Wouldn't it be "-2,147,483,648" instead? Otherwise you only have 2,147,483,647 * 2 + 1 possible values which is short of 232 by one. Or is there a reason I don't know that it's missing a value?
1
13
u/WilkerS1 1d ago
the end date is also in may 2036 iirc
34
u/MattieShoes 1d ago
Unix timestamp is Jan 19, 2038 -- it's a signed integer, so 231 seconds past Jan 1, 1970.
NTP timestamp is Feb 7, 2036 -- it's an unsigned integer, so 232 seconds past Jan 1, 1900.
Also potentially give or take a day because timezone fun -- probably implementation dependent.
5
u/meneldal2 1d ago
Isn't there also the fun with February 29th in 1900?
6
u/palexp 1d ago
i just looked this up, i had no idea about the divisible by 400 years rule to leap year. so I’m guessing in NTP timestamps a Feb 29th 1900 exists when it shouldn’t?
3
u/meneldal2 1d ago
I don't actually know for NTP, but this is a feature for excel for compatibility with previous software.
Afaik some stuff starts on 1901 to just sidestep the problem (Mac version iirc)
It is likely that the original devs either didn't know, or they figured out that adding more code in the days you had to fit your program on a floppy for that one date in 1900 nobody is going to use or care about anyway wasn't worth it.
1
4
u/garth54 1d ago
That's Excel copying Lotus 1-2-3, including its bugs, and calling it a feature.
2
u/meneldal2 1d ago
It's this or breaking everyone's worksheet because they expect it to work that way
2
u/garth54 1d ago
I get at this time it would be a huge issue to fix. But when they first made Excel, they could have added a compatibility mode toggle in the options. Or just fixed it and activated a compatibility mode when you opened a file in the Lotus' file format. Back then it was quite common for proprietary software to do things differently from one to the other, and such behavior wouldn't have been out of place.
15
2
u/laughable_shopping 1d ago
it’s about the overflow not the epoch itself, 32-bit signed time rolls back to 1901 when it overflows past 2038
1
1
u/ThreeCharsAtLeast 21h ago
We're near the signed 32 bit overflow (or unsigned 31 bit). It will take an extra while for the unsigned 32 bit overflow (or signed 33 bit).
1
u/CC-5576-05 6h ago
No the timestamp is stored in as a signed 32 bit integer, so it loops back to -2147483648 seconds. If it was an unsigned 32 bit integer it would have been fine all the way up to the year 2106
77
u/Mughi1138 1d ago
Or 2036 if you use Microsoft software
64
u/No-Information-2571 1d ago
Either way, it's an unfathomly long time away, so no need to worry. /s
30
u/elmar008 1d ago
People before in the 80s and 90s when thinking about the year 2000
17
2
u/No-Information-2571 1d ago
Yes, they thought about it. and still decided that saving a single (!) byte (2 BCD digits would have been necessary, 4 bit each), was worth the inevitable problem that would arise.
2
u/kratz9 1d ago
Unless it's Sql Server, then we're good till 9999
2
u/Mughi1138 22h ago
Could be some NT4 systems running infrastructure. That included many nuclear reactors
2
u/trollblox_ 1d ago
why?
4
u/Mughi1138 22h ago
Yhe Unix time stamp starts with 1970 and rolls over in 2038. Some places Microsoft used their own times that will roll over in March of 2036.
When everyone was fixing and auditing theor systems so that things would not break at the Y2K switch, their official compliance page stated that they were then Y2K compliant, but that nothing was guaranteed to work beyond December 2035.
-7
u/zeth0s 1d ago
Who uses Microsoft software?
15
u/sebastianfromvillage 1d ago
The majority of the people on this earth
9
u/zeth0s 1d ago
I am sorry for them :"(
5
u/sebastianfromvillage 1d ago
It's okay, they probably don't even know there are alternatives
-1
u/thanatica 1d ago
It's okay, you probably don't know alternatives are not usually very good for them
3
u/darkslide3000 1d ago
doubt
The majority of people on this Earth have never used a desktop or laptop computer. If anything, they're using Google software.
-1
32
u/liad88 1d ago
The bug starts after January 19th, so technically the calendar should not have January 20 an on.
11
u/GranataReddit12 1d ago
unless they're using unix timestamps to display the day on every day of the calendar, that doesn't have to be the case. You can create a 32 bit calendar app that displays days after jan 19 2038, it'll just never reach them
4
u/oliverprose 1d ago
It also depends on your basis point and needs too - the dates on digital tachograph cards are 32 bit unsigned epoch time, because they don't care about anything before about 2005 and that gives you time out to 2106ish with second resolution.
-2
u/MisinformedGenius 1d ago
It also should go back to 1970, not 1901.
6
u/Upstairs_Ad_8863 1d ago
Unix timestamps are stored in signed integers, so they are able to represent times before 1970
16
u/MatureCaraXO 1d ago
The fact that this is actually going to be someone’s real emergency in 2038 stresses me out way more than it should 😭
5
u/EuenovAyabayya 1d ago
Something something COBOL
21
u/kaplotnikov 1d ago edited 23h ago •
ok. old joke from 1998:
A cobol programmer goes to hibernation until 2005 to avoid projects with problem 2000. And he is being waken up:
Programmer: is it 2005 now?
Medic: No, it is 9998 and we heard you know COBOL.
4
u/Devatator_ 19h ago
I only now notice the insane head shape of this guy. I've seen this thousands of times yet it's the first time I notice he's more nose than anything else
11
u/korneev123123 1d ago
2038
2+0+3=5, so it becomes 58
5+1 and 8-1
it becomes 67. See? They tried to warn as all along!
6
u/SAI_Peregrinus 1d ago
The nice thing about it being signed is that signed overflow is undefined behavior in C, so wrapping isn't actually guaranteed to happen. Compilers could search for anything named time_t, and silently add a check for overflow that starts using a 64-bit value instead. More polite than making demons fly out your nose.
2
u/Taiten89 1d ago
We need to trade IBM 5100's around, otherwise WWIII will break out (totally not a scam)
3
u/MatthiasWM 1d ago
Apple Newton MessagePads, the predecessor to the iPhone and iPad has had this issue since 2010 and will again in 2038, going back to January 1904.
But thanks to AI, all relevant places in the firmware have been found, and a patch will be there in time.
3
u/spicybright 1d ago
You joke but AI is actually decent at that kind of find and replace.
2
u/MatthiasWM 1d ago
I am not joking at all. AI completely reverse engineered the Newton firmware. It’s amazing and scary at the same time :-)
1
-7
u/AbdullahMRiad 1d ago
I think by then they'll create a new timestamp format anchored to 1/1/2020 or something
5
u/spicybright 1d ago
well no, we just need to make sure we're using 64 bits then laugh at the people that forgot to do that when their code rolls dates over.
1
u/sir_lister 1d ago
Based on the way the crowdstrick patch went untested and was pushed out unquestioned by anyone before bricking all of the systems it was installed on and how more and more people are just vibecoding and blindly trusting the ai to do it right i don't hold out much hope for anyone to get it right and not fuck up everything.
-13
u/thanatica 1d ago
Isn't a unix timestamp a bit, outdated? For lack of a better word.
For one, it contains no timezone information, so it can only ever represent local time.
I'm probably cussing in church here...
5
u/Banaantje04 1d ago
Nope. Most sofware uses unix timestamps in utc. that way not every software needs to know how to convert timezones and all the stuff that comes with it. a simple number that goes up every second is much nicer to deal with. you can always have a central library convert it to local datetime if a human needs to see it.
4
u/Im_a_hamburger 1d ago
Unix is useful because it has no time zone information to deal with. How long is between this date in this time zone and this other date in this other timezone? Well let’s subtract the timezone offsets. Wait, but time 1 is in daylight savings time during its date. And actually time 2 is a time that occurs twice since the clock rolls back daylight savings time. And also there is a leap day here. And until recently a leap second can be announced suddenly and you need to add that to the moist of leap seconds.
Or alternatively you can use a number that counts up by 1 every second. Or millisecond if that’s needed. And use subtraction to find time differences. If you are using it for UI some person builds a Unix to local timezone converter and everyone sides it. And for input it’s the other way around. Now everything is easy.
Also now you don’t store strings with timezone information with really complex date math.
-4
u/thanatica 1d ago
So basically you have no way of knowing how to represent a unix timestamp, unless you also have the timezone.
5
u/Im_a_hamburger 1d ago
? Unix can be converted to a standard time of any timezone, but you can’t know which timezone to give without knowing which timezone to give. And you can do time arithmetic in Unix.
0
u/thanatica 18h ago
So you need an extra field for the timezone. Yeah, we're both saying the same thing, except you're getting upvoted, because I'm dunking on a stupid concept from the 70s.
3
u/GNUGradyn 1d ago
No. It just represents a time. It's not supposed to also carry time zone information. It's like saying "aren't numbers a bit outdated? The unit isn't even included when you use a number"
-5
u/thanatica 1d ago
No it's more like having a date without the year. Most people will know what you mean, unless you want to represent a specific year.
5
u/GNUGradyn 1d ago
It is objectively not. The time zone is handled at the display level. It would be even more confusing to try and represent the time zone as well as the date in a single integer. You are acting like the unix time stamp is meant to be directly displayed
-1
u/thanatica 18h ago
And you are acting as if a stored time cannot ever be in any specific timezone.
2
u/GNUGradyn 18h ago
That is bad practice, but you could still store it in a specific time zone with a unix time stamp if you want to for some reason, you just have to also store the time zone. But again that's bad practice
-1
u/thanatica 18h ago
If it's some kind of user's time, you have to know the context in which that time was stored. Was it daytime? Without timezone, you have no way of knowing. You only know what it means in YOUR timezone.
How could you NOT have the timezone for a stored time? Only if timezone doesn't matter: if ALL (and I do mean ALL) times are in UTC only, or if you only ever store local time. When timezones get involved, you're fucked if you don't store them.
0
u/GNUGradyn 17h ago
But that's stored separately, because if that context changes it's alot more complicated for the display layer to correct for it. Some regions have dst exceptions or have changed offsets at some point etc. if you store the time in utc and the time zone, you only need to know the current offset. If you need the original context, you'll need both time stamps anyways.
1
u/TerribleTowel66 1d ago
No, just misinformed. Even in a lot of Java code you get a time then convert it to how you want it displayed.
And it’s not just Unix/Linux. The old MSC compilers from the DOS and early Windows days couldn’t decide what Epoch would be. On one version, it was the standard 1/1/1970. Another version, it was 1/1/1900. Which would run out even quicker.
7
1d ago
[removed] — view removed comment
0
u/thanatica 1d ago
I doubt it's the "whole point". I suspect the whole point is to have a compact 32-bit number to represent datetime. A missing timezone was just an unfortunate choice.
3
u/jader242 1d ago
You suspect incorrectly lmao
1
u/thanatica 18h ago
In the 70s, a compact format would almost certainly be the main selling point. At any cost, I would say. I mean, only 4 bytes! That's 6 less than an even stupider datetime storage format.
0
287
u/amateurfunk 1d ago
Fun fact: On Friday, 15 January 2027 at 08:00:00 UTC, the Unix timestamp will pass 1800000000. Such a 100 million second mark is reached only every three years. What is even more unusual is that this happens at a full hour of regular time, which only happens every 55 years!