[zokier]

The problem with "seconds since epoch" expression is that almost always it doesn't mean literally seconds since epoch, but instead some unix-style monstrosity. And it's annoying that you need to read some footnote to figure out what exactly it means; it's annoying that it is basically a code-phrase that you just need to know that it's not supposed to be taken literally.

[ralferoo]

> it doesn't mean literally seconds since epoch, but instead some unix-style monstrosity

That "unix-style monstrosity" is literally seconds since the UNIX time epoch, which is unambiguously defined as starting on 1970-1-1 0:00:00 UTC.

Or it would have been, had leap seconds not been forced upon the world in 1972, at which point yes, arguably it's no longer "physical earth seconds" since the epoch but "UNIX seconds" where a day is defined as exactly 86400 UNIX seconds.

In retrospect, it'd have been better if UNIX time was exactly a second, and the leap seconds accounted for by the tz database, but that didn't exist until over a decade after the first leap seconds were added, so probably everybody thought it was easier just to take the pragmatic option to skip the missing seconds, exactly the same way that the rest of the world was doing.

I'm still not sure if that's what your complaint is about, as I don't know of time systems defined any other way handle this correctly if you were to ask for the time difference in seconds between a time before and after a leap second.

Maybe a better question would be: what do you think would be a better way of defining a representation of a date and time, and that would allow for easy calculations and also easy transformations into how it's presented for users?

[edflsafoiewq]

You literally did the exact thing GP is complaining about.

[fluoridation]

It's unclear if that's what they're complaining about, but if it is, the reason people just say "seconds since epoch" instead of saying what they actually mean is precisely because no one wants to get into the weeds of leap seconds. POSIX timestamps are a convenient format and they represent an idealized "second" of constant length that's in a uniform correspondence with the rotation of the Earth. Most likely if you're using such a representation you won't care that 1723740711 is not literally and exactly 1723740711 seconds since 1970-01-01T00:00:00Z and the error of a few seconds will not even be noticed.

[edflsafoiewq]

No, that is literally exactly what they just complained about.

> And it's annoying that you need to read some footnote to figure out what exactly it means; it's annoying that it is basically a code-phrase that you just need to know that it's not supposed to be taken literally.

Even to point of deferring the real explanation to a secondary paragraph.

[ralferoo]

It seems you're arguing based on the assumption that real time is exactly 365x24x60x60 seconds every year or exactly 366x24x60x60 seconds on leap years. It's not.

The problem is that we have a very precise definition of a second in terms of decay of atoms (maybe precise is the wrong word, as it's the statistical likelihood of x atoms decaying given certain conditions, but whatever). The problem is arguably that this is over-defined.

There's a good case that a second is actually how it's always been defined historically up until 1967 - as 1/60th of a minute, which is 1/60th of an hour, which is 1/24th of a day. That's what UNIX seconds are. 86400 of them in one day. And we have a pretty good idea what a solar day is, and have been doing calendars based on them for thousands of years.

But if you want to base your times on the decay of caesium, then you can do that, but you have to accept that it no longer corresponds neatly to a solar day any more. The length of a day fluctuates by a couple of seconds a day in either direction, which we largely just ignore because over time, that mostly cancels out. Personally, I don't think leap seconds should ever have been introduced - over the last century or so, the earth has been rotating "faster" than our idealised second based on radioactive decay, so we've added leap seconds. But more recently, it's been rotating "slower", and we're at the situation where we need negative leap seconds. Maybe really, we should have just left it alone and over a longer period it'd all have averaged out anyway.

But what's interesting is that apart from the meddling with leap seconds, we've decided that a "typical day" has exactly 86400 seconds where a second is some constant time, even though that isn't true of the reality of our planet. Some days are too short when defined this way, some days are too long. But on average, this 86400 seconds is pretty much right.

And arguably, any day that needs a leap second isn't "wrong", the problem is actually that we over defined a second before we realised that the periodicity of the solar day wasn't a constant. I wouldn't advocate trying to redefine what a second is again, because actually having a constant time second is incredibly useful for defining all the other derived SI units. But with that usefulness, you also need to be aware that it's not the same as the traditional timekeeping second.

But in any case, except for leap seconds, all the world's time systems agree on 84000 seconds per day. So, can you make the case for why you think UNIX time in particular is a problem? And what would you rather have instead?

[da_chicken]

Because sometimes when you measure time you want to know what fraction of the day it is, and sometimes when you measure time you want an objective measure of the passage of time.

Quite often, we want to use something originally recorded using the former to calculate the latter. It is most convenient to have a second that is of fixed duration. Which is kind of exactly why the tz database exists in the first place.

Except it's made more complicated because most systems that use unixtime also use NTP, and that means they employ smearing because essentially nothing in computing supports 23:59:60 or 23:59:61 or repeated seconds of 23:59:59. So on the day of the leap, the recorded time for events doesn't match standard time. Which is why the unsmear library exists (among others, probably).

Note that TAI (international atomic time) truly is the number of actual seconds since it was first synchronized in 1958. That is what is used to define UTC, and it's about 30 seconds ahead of UTC currently.

All that is to say... Calling unixtime "seconds since epoch" is a forgivable sin in terms of the practicalities of communication, but it's not really defensible as a matter of being a factual description of reality. The truth is that the new definition of a second was agreed upon decades before Unix came along, and when we're measuring time in seconds we don't typically care about the solar day or sidereal day. Further, there is no practical way to construct a computer or clock (barring a sundial) so that supports the original dynamic definition of time divisions. I can't even imagine how relativistic times with GPS satellites would have to work. It would be the longitude problem all over again.

[fluoridation]

I mean if they're referring specifically to leap seconds or to some other obscure complexity about dealing with real time.

[ralferoo]

Again, the same question: what would be a better solution?