Leap seconds affect Unix time too, because leap seconds are excluded from "number of seconds since Unix epoch". You can't measure the length of time intervals spanning leap seconds with simple subtraction.
They are excluded from "unix timestamps". They would still be part of the number of seconds since Unix epoch.
AFAIK, unix time skips a beat or repeats itself to remain in alignment with UTC, and just keeps chugging along.
Unix time does indeed repeat itself so as to remain in alignment with UTC. But unix time is not the number of seconds since the unix epoch.
Leap seconds are not excluded from number of seconds since Unix epoch, interpreted on a physical, TAI, UTC, typical local time scales.
However, they are indeed excluded from "number of seconds since Unix epoch", when interpreted in unix time. In unix time, those seconds simply don't exists (never happened) and the events of those seconds are smooshed sometime. Unix time representation forms a (quirky) timescale.
I'll quote a few excerpts from 'date' man page of linux, openbsd and for gettimeofday:
Convert seconds since the epoch (1970-01-01 UTC) to a date
Print out (in specified format) the date and time represented by seconds from the Epoch.
The time is expressed in seconds and microseconds since midnight (0 hour), January 1, 1970
I think that UNIX time stamps are generally a very good approximation, and if you are comparing long enough time intervals for the error to get over one second, and/or that error to matter, you are doing something wrong anyway.
For exact time interval measurements that you have to get exactly right, don't use UNIX time stamps.
You could store something as '2022-02-02 02:22:22 UTC', but try storing it as seconds since epoch, if you don't know if there will be leap seconds. Not to mention software that may be years or decades old.
https://en.wikipedia.org/wiki/Leap_second#Binary_representat...