Unix timestamps also get a bit weird because of leap seconds. Unix timestamps have no support for leap seconds (the POSIX spec says a Unix day is always exactly 86400 seconds), so they're usually implemented by repeating the same timestamp twice. This means that the timestamp is ambiguous for that repeated second - one timestamp actually refers to two different moments in time. To quote the example from Wikipedia:

Unix time numbers are repeated in the second immediately following a positive leap second. The Unix time number 1483142400 is thus ambiguous: it can refer either to start of the leap second (2016-12-31 23:59:60) or the end of it, one second later (2017-01-01 00:00:00). In the theoretical case when a negative leap second occurs, no ambiguity is caused, but instead there is a range of Unix time numbers that do not refer to any point in UTC time at all.

Some systems instead spread a positive leap second across the entire day (making each second a very very tiny bit longer) but technically this violates POSIX since it's modifying the length of a second.

Aren't timestamps fun?

Luckily, the standards body that deals with leap seconds has said they'll be discontinued by 2035, so at least it's one less thing that developers dealing with timestamps will have to worry about.

Don't try to write your own date/time code. Just don't. Use something built by someone else.

[–] [email protected] 3 points 8 months ago (1 children)

Luckily, the standards body that deals with leap seconds has said they’ll be discontinued by 2035

Did they figure out a way of making the earth spin more reliably per how the humans want it to?

[–] [email protected] 3 points 8 months ago

If I remember correctly, they're updating the standards to allow for more deviation between UTC time and "actual time". They'll likely replace leap seconds with a leap minute that happens much less frequently, implemented by spreading it across the whole day, similar to the leap second workaround I mentioned.

[–] [email protected] -1 points 8 months ago* (last edited 8 months ago) (2 children)

Unix time doesn’t help with timezones… It’s always in UTC.

Unix timestamp is always in UTC which is why it's helpful. It's seconds since Jan 1st 1970 UTC. Libraries let you specify timezone usually if you need to convert from/to a human readable string.

Don’t try to write your own date/time code. Just don’t. Use something built by someone else.

...yes that's why UNIX timestamps are helpful, because it's a constant standard across all the libraries.

Some systems instead spread a positive leap second across the entire day (making each second a very very tiny bit longer) but technically this violates POSIX since it’s modifying the length of a second.

Then that system should be trashed.

[–] [email protected] 2 points 8 months ago* (last edited 8 months ago) (1 children)

Unix timestamp is always in UTC

Careful with the exact phrasing here - while the epoch was at midnight in GMT, the time from which time_t is measured also exists in other timezones.

[–] [email protected] -5 points 8 months ago (1 children)

Then that the library that does it should be trashed.

https://en.wikipedia.org/wiki/Unix_time

[–] [email protected] 0 points 8 months ago

UNIX time is trash.

[–] [email protected] 2 points 8 months ago* (last edited 8 months ago)

Unix timestamp is always in UTC which is why it’s helpful.

Any time you show the time to a user, you have to use a timezone. That's why the unix timestamp has limited usefulness - it doesn't do a lot on its own and practically all use cases for times require the timezone to be known (unless you're dealing with a system that can both store and display dates in UTC). Even for things like "add one week to this timestamp", you can't do that without being timezone-aware, since it's not always an exact number of seconds as you need to take Daylight Saving transitions and leap seconds into account.

Then that system should be trashed.

A lot of systems just don't handle leap seconds well. Many years ago, Reddit was down for four hours because their systems couldn't deal with leap seconds. Smearing the extra second across the whole day causes fewer issues as software doesn't have to be built to handle an extra second in the day.