That's not true. Unix time is specifically defined as "A value that approximates the number of seconds that have elapsed since the Epoch."
Are you perhaps confusing that with the standard algorithms for converting between Unix time and "human" time? Because what you say isn't wrong for that case, and this is a classic trap for new players:
"A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below.
If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types:
> That's not true. Unix time is specifically defined as "A value that approximates the number of seconds that have elapsed since the Epoch."
It's missing 27 seconds that elapsed since the epoch. (Plus whatever happened with rubber seconds before 1972). Maybe that fits within the definition of approximate.
But if you need to record events that happen on a leap second or the second before a leap second, unixtime is unhelpful.
If you want to record a duration that includes a leapseconds, unixtime is unhelpful, although if the duration is long enough, the difference may be of no consequence.
Do you think UNIX epoch offset is different for "the second before the leap second", "the leap second" and the "second after the leap second"? If so, how? If not, then we can't rely on differences between UNIX epoch offsets for measuring intervals can we?
Moreover, if the units you are referring to are "seconds" then the statement "[t]he UNIX timestamp is literally the count of units past the epoch" is also wrong. If not, what are the units here?
Are you perhaps confusing that with the standard algorithms for converting between Unix time and "human" time? Because what you say isn't wrong for that case, and this is a classic trap for new players:
"A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below.
If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types:
tm_sec + tm_min60 + tm_hour3600 + tm_yday86400 + (tm_year-70)31536000 + ((tm_year-69)/4)86400 - ((tm_year-1)/100)86400 + ((tm_year+299)/400)*86400"
(Quotes from https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...)