If I understand what people are saying correctly, this is actually not true; leap seconds can not be referenced in Unix time and are not included in the unix timestamp value. They're just ghost seconds during which the counter stopped for one second. Which is not the way the system should have been designed, in my humble opinion. All seconds should be referenceable.
UNIX time does not represent/reference calendar time, it represents the number of physical seconds since 1970-01-01UTC. How you translate that into local calendar time is up to you!
The article's assertion that Unix time treats days as 86400 appears correct to me. Both Python and Javascript report 12-01-2019 UTC as the Unix timestamp 1575158400, 12-01-2000 UTC as Unix timestamp 975628800, and the difference between those is 599529600, which is exactly 19*365 days + 4 leap days as 86400 second days.
The leap seconds added in 2005, 2008, 2012, 2015, and 2016 are all uncounted there. If Unix timestamps were the count of physical seconds that had passed since 1970/1/1 UTC, then the end result of my test should have been 599529605 instead of 599529600.
