Glibc is still not Y2038 compliant by default

Which part is ironic?

Thankfully upgrades move faster in the OSS world. The worrysome cases are embedded systems. Especially those built intentionally 32 bit.

I have no clue how widely implemented it is, but as far as NTP is concerned we're currently in era 0 which spans from 1900 to 2036. When we reach 2036, we just move to era 1 and have another 136 years until we reach era 2. NTP itself should be resilient to this kind of issue by design.

They and everybody else should avoid using timestamp representations for any dates so far in the future. Because, it is a nightmare to translate timestamps when the timezone database is updated. Which you would have to do, if e.g. the EU finally manages to get rid of summer time and you care that dates past that change stay the same.

Finance/insurance generally sticks to dates instead of timestamps for most of its data, especially since the effective date might be different from the timestamp date (e.g. a weekend or night transaction having the value date for interest calculations set to the next business day; but you also might have backdated transactions caused by various corrections). Timestamps and timezones are used for logs and auditing, but for settling money it's generally considered that the thing that matters is at the granularity of a whole date.

Of course there are things like HFT where precise time matters a lot, but there you don't schedule things years in advance, all the long-term things like mortgage schedules and insurance terms simply ignore time and timezones.

This is false. Many, many embedded systems simply use glibc. I wouldn't go so far as to say "most" embedded systems do not use glibc.

DateTime processing and system time are often handled separately with some system time to datetime time conversion.

Bingo. We have the option of recompiling with an older version of glibc while we work out the bugs. Our users won't have the option of running our code in 2037 when the epoch arrives.

I think it lets developers opt-in to fixing their glibc-dependent programs ahead of time, so there's less work to do on stage 3.

> Is phase 2 that useful?

Yes for preparing the upgrade seamlessley for developers, administrators and users.

you can prepare your buildscripts before it breaks, you can build it easier as feature/forward/backward toggle

same logic and code with different toggles is better

64-bit glibc has always had 64-bit time, all this matters only to 32-bit applications.

In other words, all non-trivial code builds would break? Sounds unreasonably painful.

There is no "no default", your distro will ship with one or the other. Very few people compile and ship glibc, upstream defaults only matter in the way they affect distro defaults.

That would be untenable - I wouldn't be able to cleanly `gcc -o blah blah.c` without making an explicit decision, and by extension wouldn't be able to (continue to) compile existing code either.

Rebuilds on every codebase everywhere ever would promptly blow up.

IMHO the revolts would come from two camps, a) bureaucracies for whom a build system change would normally take months, and b) individual devs who would be all like "compilation flags?? in MY defaults?! that's LESS likely than you think!".

Worst case scenario, someone forks glibc, removes the offending requirement, proffers commercial support for their fork... and ends up making bank.

I think that would be a bad idea in this specific case.

Why? Because for the majority of codebases, the time_t change won't require any work.

You'd be forcing a compiler error, and it would effectively say "Add -D_TIME_BITS=64. If you're doing something really weird with time_t then you may have to update your code too, but in 95% of the cases, you can just add that flag."

I think the compiler error might be warranted for something like "You are using a function that is 95% of the time insecure or wrong, please add -DGAPING_SECURITY_HOLE if you know what you're doing", but if the error really is just "add a flag, you do not need to think about your code probably", the library authors themselves might as well default it for you.

If you spend large amounts of money today, fixing a system that is later decommissioned in 2029 or 2032… you wasted a lot of money.

The correct play could very well be to wait to the last second and pay absurd money for scarce experts to fix the systems.

> I was feeling the same, about the only thing I have using 32bit userspace these days are a few rPIs, little bit early to be panicking they may suffer from the Y2038 bug

Quite the opposite if you're talking about rPIs: the small/embedded space is where things can live for a long time. They're the primary place to worrying about. Especially if you're talking about industrial processes.

But if we techies get way ahead of the problem this time, maybe we can prevent it becoming a mass hysteria as Y2K was.

Oracle Linux for ARM is purely 64-bit, with no 32-bit support at all. Busybox 32-bit binaries will run, but only 64-bit RPM packages are offered.

Aside from Android, it is the only ARM distribution that I know of with this property.

> Sure. And the ABI needs to break sometime before 2038.

That really highlights the benefit of the BSD model, where the OS, libc and all the base packages are shipped as a complete system. OpenBSD switch to 64 bit time_t on all supported platforms back in 2014. We all talked about Y2038 back then, and most agreed that something should be now as quickly as possible. Then the world just sort of forgot. I mean it is solved, but if you're a new developer, you might not know that you need to do something special.

The GNU and Linux world is really good at not breaking ABI compatibility and mostly that's great, but in this case it's a problem and pushing it much further is going to be a problem. It's also going to be weird if the default never change, then we just have a C library that that just keep producing defective programs, unless you add certain flags.

glibc itself doesn't break ABI, it provides both 32-bit and 64-bit functions, just defaults to the wrong portion of them on the C API level.

> If you jump between incompatible versions of a C library without rebuilding, you can expect nothing to work.

Is there a reason musl introduced this in a non-major version? Your point here is perfectly valid, but to me the next obvious question is "what qualifies as an incompatible version?", and after doing some Googling I'm surprised it's not very clear to me. I would have assumed that going from 1.1.X to 1.2.0 was compatible, or IE. two programs compiled against 1.1.0 and 1.2.0 will work fine together, but clearly that's not actually the case.

The engineer inside me cringes, while the Businessman cheers ;)

What’s the alternative to rewriting? Just recompiling?

Assuming the code on the receiving end stores the value in 32 bits (and not a time _t which can magically change meaning but a 32 bit integer) then it’s still doomed without rewrite?

I mean even with time_t use you can’t just recompile and make it work because there could be subsequent assumptions that the size of a struct containing a time_t will be a specific size or allocations will be too small or misaligned and so on.

For open source software, it’s a simple recompile. Most OSS compiles are 64-bit these days, where time_t has always been 64-bit. In the case of compiling a new 32-bit application, -D_TIME_BITS=64 apparently needs to be a compile time flag.

For binary software, Windows has had a Y2038 compliant proprietary API since Windows NT in the 1990s; most Windows applications use this API so Y2038 is generally not an issue.

The issue only affects a subset of 32-bit binary-only applications where we don’t have the source code any more. Hopefully, any and all applications like that will be decommissioned within the next couple of years.

Since 10.15 only 64 bits code is supported anyway.

Honestly, for network code it makes more sense when the data is received to add the time to the current era. A 64 bit timestamp is an extra 4 bytes of overhead. However, the biggest issue with a network protocol is you just can't force everyone to update everything.

Now it's some in house protocol sure you can just update everything instead making the timestamp a relative value to the current era.

For code running locally 64 bits is less of issue, just mainly a problem of ABI breaks.

Honestly, one thing I think people overlook is file-formats... A lot them have 32 bit time fields. Also unlike a network packet the file could actually be from a previous 32 bit era. So those timestamps are ambiguous after 2038.

> Lots of code would break because they assume they can do signed math with time_t, though.

And lots of code would break because they want to talk about pre-1970 dates.

I'm definitely guilty of it, as I routinely use the timeline of the Great Emu War (1932-10-02/1932-12-10) to test time-bound features.

> it's just a recompile, except for code that persists a time_t directly or sends it directly over the network

Wouldn’t it also fail for all code that

a) stores the return value in a plain int and not a time_t as it would truncate (but at least this is a warning)

b) has time_t inside struts and allocates their size or arrays of structs assuming time_t is 4 bytes

c) has time_t inside structs and assumes the byte alignment of fields following it

Etc etc..

Another tradeoff is that you can't just subtract two time_t's and get a negative value for an interval. I'd wager this is a far more common problem.

E.g. you can't do...

    time_t completion = time(NULL) + 30;
    
    do {
        time_t remaining = completion - time(NULL);
    
        /* ... */
    } while (remaining > 0);

Without risking a sporadic infinite loop.

Optimistically assume we as a species manage to survive to the point where distance, or relativistic speed differences, cause sufficiently frequent change in the observation of time passing that a single number, of any size, is no longer sufficient.

time_t is sufficient within bounds. It is expedient and quite correct in many computer science use cases. It can be extended with small additions for many other use cases.

However those bounds are a set of assumptions and simplifications that shouldn't be forgotten. I agree that the problem would be solved until the next paradigm shift in our understanding of time and the universe, and maybe forever if it turns out that the rules are cruel or we're too stupid to reach a more complex situation. I just wouldn't say once and for all, there's far too much uncertainty there.

ah interesting I hadn't realized. but for sure lots of problems will start occurring starting 2038

time_t has always been 64-bit on 64-bit glibc (https://sourceware.org/glibc/wiki/Y2038ProofnessDesign , https://www.gnu.org/software/libc/manual/html_node/Feature-T...).

> Currently it defaults to 64 bits on most architectures. Although it defaults to 32 bits on some traditional architectures (i686, ARM), this is planned to change and applications should not rely on this.

This is certainly not true:

  #include <time.h>                                                                                                             
  #include <stdio.h>                                                                                                      
  int main() {                                                                                                                    
      printf("size: %lu\n", sizeof(time_t));                                                                                  
      return 0;                                                                                                       
  }

prints 8 on my system when compiled with just "gcc test.c"

When Y2k happened, it also seemed a little ridiculous to laypeople because they thought, "Surely we don't depend on computers that much," and there was still an institutional memory of doing important business on paper. Nobody is under that illusion now.

I'm assuming that you're also building all your dependent libraries as part of your build process, as is common with languages like Rust. Closed source libraries are somewhat out of scope when talking about Linux distributions, though you can always ask the vendor to provide you a 64-bit compatible library.

Nothing wrong with fixed point. It's only a problem because people end up hand-rolling their arithmetic (and botching it) instead of using library functions that do it right.

You could use arbitrary precision rational numbers.

Many languages support these in their standard libraries. (Eg Python does.)

They are a bit slow compared to ints or floats, but good for precision.

Fixed point could work, and they are certainly better than ints, but floating point behaves more like people expect timestamps to work, and the specific fixed-point I need never seems to be available.

Timestamp ints get constantly casted back and forth between seconds, microseconds, and nano seconds. its an absolute mess everywhere. This are fixed point floats. Everything sensor related, and countless logging, file or anywhere wait_for or timeouts are used are typical usecases, and indirectly whenever people need to do simple things like basic arithmetics on timestamps. The code will either contain some precision change or a unfixed bug related to overflow of one or more kinds.

So int64 is half, and I was off by a factor of three doing it in my head... I was wrong no doubt about that. But the order of magnitude is the problem, it should be millenia, or millions of years, not a few centuries.

How are you going to represent 0.3 using a non fixed point integer? And if you do, use fixed point, you suddenly have other just as common numbers you cant represent. You really think NaN is a better is a less intuitive result than what whatint64(1)/int64(0) gives? You really think the latter wont result in a bug as well?

gettimeofday is deprecated as of 2008. So even using it is a bug. Using it more than a few times per seconds is almost certainly a bug. The function also uses an ambiguous representation, but and as the docs dont specify, I would have to check the code to se if it relies on microseconds being less than 10^6, and even if I check this for standard glibc, I would not trust other implementations to do the same. However, as we can assume that the pseudo integer type used does not need to use have multiple codes for basic numbers, its easy to se that the range is just under 52 bits. gettimeofday is so old that they didn't even expect that emulated int64 was available. That is, if they used a double instead, it would perfectly cover the same range, require much less code, while simultaneously been easier to get right, support all standard operations you would expect, behave more intuitively in many cases, and be faster on most platforms, though as you say, perhaps slightly slower on soft float platforms. Though I woudnt be so sure, almost every project notices float performance, almost no project notices gettimeofday performance.

The ABI would break by changing the type regardless, numeric types should never be used without explicitly specifying precision, and no, the burden is primarily on compilers. With float128 as a core language feature as it should be, noting that while it should be IEEE... compliant, it may be emulated, the burden on the distros would be small, and likely net beneficial as timestamps is one of those things that cause very rare and hard to replicate bugs absolutely everywhere.

Because in every situation I have ever run into a floating point timestamp behaves more intuitively, and when I started converting my programs to use floating point timestamps almost every function that used timestamps lost dozens of hard to understand special cases that accounted for int overflow, unsignedness, etc problems. Problems which every single one had bit me in the ass at least once before I wrote the code managing the special case, and of which nearly every single one had at least one bug in it. See the revisions to std::midpoint for great examples of how hard this is to do right. However, because float128 overrepresents all the older basic type variants, it becomes trivial. If the code could possibly have been made to work for any of them, it will automatically always work for float128.

Its got more to do with how intuitively the timestamp behaves, and that you can use seconds as the unit everywhere and no longer need to keep track of if this wait function took seconds or milliseconds. Using infty to indicate a timeout function should block indefinetly is also much more intuitive than using 0.