> unixtime is an integer, it has no concept of some seconds being different to other seconds - leap seconds only matter when converting this integer into a "human readable" format :)
Except that's not how UNIX timestamps work (incidentally that'd be TAI time, which some non-conformant systems use for UNIX timestamps, and which DJB advocated for a few years ago, issue being TAI isn't really human-friendly).
A UNIX timestamps is UTC, it's defined as 86400 * days since epoch[0] + seconds since midnight[2]. Since UTC takes leap seconds in account, so does a unix timestamp, which in most implementations means a repeated second (and if you have sub-second timestamps, lots of repeated timestamp). Which has lead to the invention of stuff like "leap second smearing" as lots of software doesn't deal well with repeated timestamps, or more generally non-monotonic clocks.
By the by, because UNIX timestamps are now defined based on UTC and UTC didn't exist before January 1st, 1972, timestamps below +63072000 are imprecisely defined and not-entirely-specified approximations of GMT.
Except that's not how UNIX timestamps work (incidentally that'd be TAI time, which some non-conformant systems use for UNIX timestamps, and which DJB advocated for a few years ago, issue being TAI isn't really human-friendly).
A UNIX timestamps is UTC, it's defined as 86400 * days since epoch[0] + seconds since midnight[2]. Since UTC takes leap seconds in account, so does a unix timestamp, which in most implementations means a repeated second (and if you have sub-second timestamps, lots of repeated timestamp). Which has lead to the invention of stuff like "leap second smearing" as lots of software doesn't deal well with repeated timestamps, or more generally non-monotonic clocks.
By the by, because UNIX timestamps are now defined based on UTC and UTC didn't exist before January 1st, 1972, timestamps below +63072000 are imprecisely defined and not-entirely-specified approximations of GMT.
[1] 1970-01-01T00:00:00Z
[2] UTC