[dheera]

For lots of use cases you want to record precise events in a universal sense, and be able to add and subtract them or compare whether one timestamp is the same exact time as another timestamp regardless of timezones.

UNIX timestamps have no timezones. They are just the number of actual seconds that have elapsed since a certain commonly-agreed time. You measure the number of seconds between two events just by subtracting their timestamps arithmetically, and don't need to do any parsing or interpreting of timezones. You can just say "this hacker in Russia breached the firewall 35 seconds after this dev committed code in the US" just by subtracting two numbers.

The time an airplane takes off, the time your firewall detected a security event, the time a cross-timezone meeting starts, these are all good to store as UNIX timestamps.

Birthdays are different because they are inherently imprecise; humans tend to celebrate their birthdays when it's a certain day of the month in their local time zone, with little to no regard for the time zone they were born in. Someone born in Singapore (UTC+8) and lives in Alaska (UTC-8) might still celebrate their 30th birthday on the month and day of their birthday in Alaska time even though their body might need another 16 hours before it has technically experienced 30 years of life.

[SideQuark]

There is no such thing as "exact same time" due to relativity. The most perfect of clocks in use on the planet will drift, and both are correct.

Mail an atomic clock easy to west, and a different one west to east, and they'll drift different amounts. Put one in a plane, it will disagree with one on the ground. Put one on a mountain, it will disagree with one at sea level. Put one at the pole, it will differ with one on the equator.

There is little sense in claiming one time is exactly equal to another. Close to some tolerance is useful.

[zokier]

> UNIX timestamps have no timezones. They are just the number of actual seconds that have elapsed since a certain commonly-agreed time. You measure the number of seconds between two events just by subtracting their timestamps arithmetically, and don't need to do any parsing or interpreting of timezones

If only. UNIX mishandling of leap seconds makes this all a illusion, in reality you need to have logic to handle them

[JohnFen]

I don't think that UNIX mishandles leap seconds. It properly ignores them because they aren't relevant to it. The UNIX timestamp is literally the count of units past the epoch. The existence of leap seconds don't affect that count, it only affects the timekeeping of a completely different scheme.

So yes, you have to handle leap seconds when you're converting from the timestamp to/from the time scheme you are interested in, just as you have to handle leap years, etc. The UNIX timestamp is just a different way of marking time, and is blessed with not worrying at all about how that time relates to the actual motion of the Earth. That makes it easy and consistent for common operations. It is not mishandling anything. It just can't shield you from the complexity of the forms of timekeeping that make it a point to be synchronized with the Earth.

[zokier]

> The UNIX timestamp is literally the count of seconds past the epoch

Nope. UNIX timestamp is days since epoch × 86400 + seconds since midnight. And that is the crux of the issue.

[JohnFen]

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:

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...)

[toast0]

I think you two are talking past each other.

> 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.

[NovemberWhiskey]

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?