Unix time is monotonically increasing, as long as there are no negative leap seconds (and there never have been). It's just not uniformly increasing, since it tracks UTC.
I think you have the concept of leap-second backwards. A positive leap-second means that the time-of-day is held for one additional second. Since unix time does not respect leap seconds there are 35 different unix time values at the resolution of seconds which refer to periods of time lasting 2 seconds instead of one.
And that means that unix time at a resolution higher than a second will jump backwards at those 35 different leap seconds.
> I think you have the concept of leap-second backwards. A positive leap-second means that the time-of-day is held for one additional second. Since unix time does not respect leap seconds there are 35 different unix time values at the resolution of seconds which refer to periods of time lasting 2 seconds instead of one.
Monotonic functions can yield repeated values, they don't have to be strictly increasing or decreasing. A constant function is monotone.
> And that means that unix time at a resolution higher than a second will jump backwards at those 35 different leap seconds.
Yes sub-second timestamps won't be monotonic, but UNIX time (or POSIX time) is only defined with a resolution of a second, so it is monotonic.
This isn't quite correct, and as the grandparent applies the concept it is definitely incorrect. A monotonically increasing function may never repeat a value. A constant function is not monotonically increasing; it is monotonically nondecreasing (and of course, also monotonically nonincreasing).
POSIX time.h defines "unix time" as seconds since the epoch in type... time_t, which (according to the POSIX standard) can be either an integer or a floating point value.
In practice though, "unix time" is merely a convention which is based off of the POSIX standard.
