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 think you're talking about struct timespec, I'm talking about time_t.
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?
One could also make ticks on such a day last 86400/86401 or 86400/86399 seconds, keeping the tick duration fixed but only for a given day (a relaxed version of B)
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.