And I guess POSIX tries to pick all three, at least most of the time. It follows UTC mostly, except during leap seconds when it changes the duration of a POSIX-second to be 2 SI-seconds (positive leap second) or 0 SI-seconds (negative leap second).
99.999998% of time_t ticks from 1970 until now have been 1 second long. 27 have been 2 seconds long. Therefore B ("each smaller time unit is of a fixed physical duration") is the variant.
POSIX time does not generally work that way. It may seem that way for 1-second resolution timestamps, but at higher resolutions (say millisecond resolution), the clock does not completely stop. It keeps going, jumps backward 1 second, then continues.
I don't think "POSIX time" specifies behavior during leap-seconds for the functions that return timespecs (gettimeofday() [0] and clock_gettime(CLOCK_REALTIME) [1]), so any behaviour would be valid - including smearing or repeating nanoseconds?
[0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/g...
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...
It preserves A (exactly 86400 ticks per calendar day) and C (remains in alignment with UTC) by abandoning B (each tick has a fixed duration)