Yes, but the point is that the UNIX timestamp doesn't count the the number of seconds elapsed since January 1, 1970. It counts 86400 seconds per day, regardless of how many seconds the day actually has (which can vary due to leap seconds).
Is this accurate though? Isn’t the number of seconds since 1970 absolute, and it’s up to the library generating the Gregorian date to take into account leap seconds?
I suppose if these libraries are not taking into account leap seconds, then the actual rollover will be a few seconds earlier (or later?) than what we think.
Your time_t isn't the true number of SI seconds since the Epoch. It's that number, mucked around 27 times so far. Instead of leaving their kernels to count one tick per SI second (ignoring oscillator drift) many people slew, step, or smear their seconds count every time that there is a leap second.
Go and read about "right" versus "posix" timezones.
IIUC unix timestamp simply counts seconds (well defined interval of time) from epoch onwards. It is then up to different calendars to interpret this number as a given day / hour /... This is the beauty of it - it is always an accurate (well, at low speeds at least ;) ) measure of time. In other words, no, some days might not last 86400 seconds.
This is not correct. UNIX timestamps always have 86400 seconds per day, and consequently, they do not actually count the number of seconds since the epoch.
