Unix timestamp assumes there are exactly 86400 seconds in a day. Or, in other words, if your timestamp is a multiple of 86400, it's midnight UTC.

There are not alway 86400s in 1 day. Midnight is not a whole number of multiples of 86400 after Jan 1st 1970.

Specifically unix timestamp is (number of days since 1970-01-01 × 86400) + (seconds since midnight). The difference arises from the fact that in utc some days are 86401 seconds long.

Another way of viewing it is that unix timestamp is seconds since 1970-01-01 minus number of leap seconds that have passed.

> If a leap second is to be inserted, then in most Unix-like systems the OS kernel just steps the time back by 1 second at the beginning of the leap second, so the last second of the UTC day is repeated and thus duplicate timestamps can occur.

So certain unix timestamp can represent two different points in time, the last normal second of the day or the leap second that happened after it. This makes (certain) unix timestamps ambiguous.

> Do leap seconds work differently in UTC or something?

Leap seconds exist in UTC, that's the entire thing.

A leap second getting inserted (which has always been the case so far, though it may eventually change) means a UTC day ends on 23:59:60, which as far as UTC is concerned is perfectly fine, nothing wrong with a minute having 61 seconds.

UNIX time though? UNIX time is (86400 * days since epoch) + seconds since midnight.

23:59:60 is 86400, so on the last second of day X you're at 86400 * X + 86400, and on the next second (the first of day X+1) you're at 86400 * (X+1) + 0.

Which is the same value. And thus one second repeats.