Then you don’t understand Unix time. In the first case it would return 7200, and in the second case it would count “made up time”.
UNIX time is 86400*days since epoch + seconds since midnight. It does not measure “real time”, whatever that is.
> Leap seconds never happened, they were added to UTC and UTC only in order to correct it for sunrise and sunset.
You’re apparently confusing leap seconds and DST. Leap seconds are used to compensate for minute variations in the speed at which the earth rotates (irregularities and an overall slowdown). So they serve to resynchronize atomic time (TAI) and solar time (UT1). This resynchronized version (UT1 ~ 1s) is UTC.
As far as Unix and UTC are concerned, many systems provide the option to smear the system clock over a 24h period (-12h, +12h) centered on the leap second. This avoids the discontinuity and can help avoid errors some incorrectly written programs may not be able to tolerate.
For leap smearing, see: https://developers.google.com/time/smear
I disagree with the statement that UNIX time is not the amount of seconds since the Epoch. Leap seconds never happened, they were added to UTC and UTC only in order to correct it for sunrise and sunset.
If we started an experiment on 23:00 and ended it on 01:00 the next day, but a leap second occured in the mean time, the experiment wasn't running for 7200 seconds, but for 7199 seconds. The leap second had nothing to do with time counting, a stopwatch would not add a second to the reading.
If we started an experiment on Epoch, the UNIX time tells us the amount of seconds this experiment has been running. If we added 86400 leap seconds in between, the experiment would count real time, not our made up time. One day wouldn't be added to the count.
As far as I understand it, that's what UNIX time is, and there's nothing wrong with that. It's a feature.
Please add your opinion.