Year 2038 problem is still alive and well
cookieplmonster.github.io
cookieplmonster.github.io
> While the native APIs of OpenVMS can support timestamps up to the 31st of July 31086, the C runtime library (CRTL) uses 32-bit integers for time_t. As part of Y2K compliance work that was carried out in 1998, the CRTL was modified to use unsigned 32-bit integers to represent time; extending the range of time_t up to the 7th of February 2106.
A Y2K38 problem fixed during the Y2K!
Admittedly that's probably a rare problem, but I can imagine it could have broken something
(An interesting tidbit: Since 2018-07-22, a 32-bit signed time_t with an epoch of 1970-01-01 has been able to represent the date of birth of every living human. Chiyo Miyako was born 1901-05-02 and died 2018-07-22 at the age of 117 years, 81 days. 2^31-1 seconds before the epoch was 1901-12-13. Reference: https://en.wikipedia.org/wiki/List_of_the_verified_oldest_pe...)
mkfs.xfs -m bigtime=1 ...
I wish I could tell you! Usually this implies some sort of lacking stability; yet I don't recall any specific warnings when I was researching opting in.
There may be some insights on the upstream XFS/Red Hat mailing lists (most of the developers are there, IIRC)
I've replaced all of my old XFS filesystems to address this and haven't noticed any problems... but filesystem things can be subtle.
I think this will bite us hard - way harder than Y2K (which happened when software was far less prevalent). There must be millions or even billions of embedded devices out there which are susceptible to this problem - the only real question is how badly they'll fail.
LGR did an excellent video [1] on the subject.
My guess is that there would have been some minor disturbances; bureaucratic snafus about life insurance and so on. But unlikely to be a collapse of society.
I think it's so you can monitor the fuel level from inside your RV or something.
I was young at the time, and I did what management told me to do but felt icky about it because I knew it was hugely inferior and they didn't know what they were doing, and I was just a tiny cog in the team doing all the changes, most of which thought it was fine... Left that place long ago.
What you recommend is an easy fix, and might work most of the time, but its wrong and will cause infuriating problems, probably making others suffer your past deeds. Just do it properly once, first time.
Companies/Tools/Projects that plan to exist beyond 2038 should just migrate their code.
This sentence reminds me of "The last question" by Asimov. Well, it's good enough for us, but "humans" 292bi years from now will still have to deal with it.
It's certainty one way to do it, but I'm pretty sure this is unacceptable to most kernels.
Adding a designation before the number, or date parsers knowing to separate the first or last digit from the rest of the number, meaning that its not just an overflowing large number its two numbers
Any undesignated timestamp being part of epoch 0
current_unix_time+1 second > current_unix_time
if time = 0
// handle missing data case
else
...
But this blog post is about how code which is already using 64 bit ints can have code which silently truncates. Another case of C's loose handling of types, whereas in Rust there would've been an explicit cast required (granted, in this case the macro expands to having explicit type casts)
That’s such a waste though. We could the current Unix time as is, and use a single additional bit to indicate if it’s the original epoch, or the new one. Imagine the net savings worldwide by using only 33 bits rather than 64 for the next 68 years.
Apple has their version. https://developer.apple.com/documentation/corefoundation/154...
https://dnsviz.net/d/developer.apple.com/dnssec/
My favorite DNSSEC issue is that Verisign's DNSSEC checker fails DNSSEC:
https://dnsviz.net/d/dnssec-analyzer.verisignlabs.com/dnssec...
At least there is an easy solution to this mess, just remove it entirely. It is obvious that almost no one uses it.
Imagine a C style packed bitfield structure similar to this:
struct t_timebf {
uint8 timesystem : 8;
sint64 timedata : 56;
}
Up to 255 standards may be defined which will define at least: an epoch for that standard, how the 56 bits for the timedata field are used to store data.
Standard 255 should be reserved as invalid (a guard against timestamp manipulation error).
Standards 254 down through 248 should be reserved in case there is a need for a program specific format that should not be handled by a standard library. The seven slots are reserved to allow up to that many revisions / variations of new timestamp types without further complicating the software.
Standard 0 might be reserved or assigned to Unix epoch timestamps. (see also 255 for folding naive manipulations back to a 56 bit timestamp.)
Standard 1 might be 56-bit microseconds (0.001 seconds), with a Unix epoch?
Standard 2 might be 56-bit milliseconds (0.000001 seconds), with a Unix epoch?
Standard 3 might be 56-bit nanoseconds (0.000000001 seconds), with a Unix epoch?
Those are (approximately) the current popular ranges of timestamps, and the reason for supporting 1e+0, 1e-3, 13-6, and 1e-9 are the approximately 30, 20, 10, and 0 extra bits of offered precision over the other timestamps.
When writing that out however, I realized that even at a full 64 bits, a nanosecond precision timestamp has a woefully inadequate number of bits. (only ~524 years of precision according to someone that did the math ( https://stackoverflow.com/questions/43451565/store-timestamp... ))
If storage isn't a concern, it might be better to utilize 128 or more bits for a timestamp to ensure there's sufficient room for the desired range. However at that point it makes much more sense for application specific choices.
A timestamp in many applications should probably include a reference timezone anyway.
In modern systems "a double-precision (64-bit) binary floating-point number has a coefficient of 53 bits (including 1 implied bit), an exponent of 11 bits, and 1 sign bit. " (Wikipedia since I had to look up the exact details).
Maybe it's intentional that the year is omitted for current year, and just a coincidence that the time is 20:22?
Pre-NT Microsoft standards used a 7-bit integer, but only officially from 1980 (0) until 119 (2099). While DOS is officially discontinued, FAT32 is still in extensive use. If we go on the endurance of FAT (in compatibility), we need a new portable file system that must be implemented by 2050. Heck, exFAT suffers from the same problem. MICROSOFT, WHY?!
Most RTC chips tends to be centennial - this means current chips only support up to 2099 or 2100 depending on the implementation.
With a reasonable implementation, that's not a problem. A clock doesn't need to handle old values, so you can assume the year is between build_date - 10 and build_date + 90, or something like that. Or at boot assume you're within 50 years of your last filesystem update.
Also huh, exFAT added a byte to timestamps to change the resolution from 2 seconds to .01 seconds, but still kept the awkward bit fields from FAT32. Also some implementations break the new byte. Just changing the bit fields to a single number would have pushed the end date to 2250.
Incidentally Y2K38.com was registered in 2002.
/s
A cornered, unhinged, elderly dictator with access to a huge nuclear arsenal does not give me comfort.
Do you have any thoughts on what/whom will be next?
- Putin doesn't go nuclear and I win the bet
- Putin does go nuclear and you aren't able to collect from me.
Heads I win, tails you lose.
(I knew it wouldn't work past 2038, I didn't realize it would keep anyone from seeing the production schedule if it contained an offending job.)
Personally, I would prefer not to reset to 1K humans on the planet.
My guess is in 2037 everyone will frantically test their systems and make some patches and life will go on, no?
A lot of the y2k thing was badly framed and over-hyped by Large Consulting Companies, but it was a real problem
On a better note Y2K brought us the movie "Office Space", so perhaps Y2K38 will give us another equally awesome movie.
"What would you say...you do here?"
- will have literally anywhere that time is 32-bit
- won’t be actively updated, but still in use.
This problem has the potential to break clocks on so many devices. Some may not be easily updatable.
https://www.gresham.ac.uk/lectures-and-events/what-really-ha...
Which does have a decent list of failures due to the Y2K issue.
It's going to hit the embedded world pretty hard. It's going to hit the "no need to update the legacy software that still works" enterprise world pretty hard.
It's not even going to be a blip on the open software world because 64 bit `time_t` has been the default since the mid 2000s.