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.

See the definition of seconds since the epoch at https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...

  tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
      (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
      ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

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.

* https://unix.stackexchange.com/a/294715/5132

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.

I stand corrected - thank you for the clarification!