No, willful misunderstanding aside, the idea is to provide a single continuous counter to apps that want it. If you look closely at most implementations, that's how many apps actually expect it to work.

There already is a continuous monotonic timer available in most operating systems, it just happens to be relative to some internal counter local to that system (and depending on virtualization layer doesn't always provide monotonic guarantees). This value can generally be translated into a fixed (and vice-versa), serialized timestamp for persistence.

I think that's mainly a problem with apps using a wall clock time (e.g. System.currentTimeMillis() in Java) when what they really want is a monotonic clock based on a hardware counter of some kind (like System.nanoTime()).

I'm not too familiar with what the clock situation is like for languages outside C/C++/Java.