[lalaithion]

Why is this the case? No one has bothered to do it? It would break backwards compatibility? Linus thinks it's a bad idea?

[jchw]

Shouldn't break backwards compatibility. More than anything, my guess is that it's just a result of most of Linux's modern day design having been implemented before the era of containers. Afaik, namespaces+cgroups were never meant to support complete isolation.

[simcop2387]

The time namespace is being worked on, it's a very difficult problem because of how pervasive time is in the kernel.

Here's a recent in depth LWN article about the topic. https://lwn.net/Articles/766089/

They keychain stuff I haven't heard about any work being done but I don't know any reason it shouldn't be doable.

[emmelaich]

Probably merely because it's hard to do and no one has sufficient motivation.

I can think of one good use case -- y2k style problems.

Also sometimes apps are tied to external events like legislation. It would be good to set the time forward for testing.

You can sort of do this with LD_PRELOAD but it can get hairy.

Also see @wmf's comment above.

[etaoins]

Another use case is dealing with tokens that assume globally synchronised clocks such as JWTs and Kerberos/Active Directory. Ideally all clocks would be perfectly synchronised but things happen.

For example, you might have one container that’s exchanging JWTs with a micro service that should be using AWS’s NTP servers and another that’s joined an Active Directory domain that should be using the AD NTP server. Right now you either need to run them on separate machines or expose yourself to interesting problems if clock skew happens.

[briffle]

If there is one thing Y2K taught us, its to ignore any worry about the 2038 problem until 2036, then make a HUGE deal out of it.

https://en.wikipedia.org/wiki/Year_2038_problem

[cyphar]

Linux and glibc have been working on 2038 problems for at least the past decade.

[pjmlp]

There are plenty of other POSIX platforms out there.