Basically we guessed wrong. We thought knowing "Solar time" would be more useful than in it, and we thought these "Leap seconds" would be less trouble than they are.

It's like you buy a cat to help with your rodent problem, figuring the cat will eat mice and isn't much trouble to look after, but after purchasing a cat you find that your problem was actually rats, your cat is terrified of these large dangerous creatures and sometimes gets bitten by them necessitating expensive vet bills and now you need to pay a lot of attention to the poor animal and also now need to buy cat food.

Heh, I like the analogy but my question was really why it was considered such a hassle.

I mean we deal with daylight saving time all the time and I know it's not the same because the leap second affects UTC, not just local time zone, it's just that you are either dealing with monotonically increasing time like epoch, or you are dealing with "human" time and I found no distinction in the latter.

Is it "just" that leap seconds or delay seconds caused problems in epoch to utc conversion? Note the just in quotes, but did I just answer my own question? :)

It's a hassle for anybody doing or recording "physics" as they cannot log against UTC (which may or may not have an added second or removed second in some interval if it happens to overlap the adjustment zone).

Those things that really do rely on actual "elapsed time" rather than the difference between two recorded "book times".

Does this happen? Yes, a few times in my career in geophysical exploration - it's why multiple bits of gear are synced to a reference "real clock" which gets logged against the raw GPS epoch time (real time since Sunday last week(?)) and processed "UTC" time (some variation of it).

The most annoying part is that a lot of GPS gear automatically "corrects" to UTC without giving clear indication of it. Things would'be been fine if the standard was to explicitly sent out TAI timestamps, with a leap second offset for the people who insist on UTC.

Well, yeah, that to - although TBH it's never been an issue in my line of work which started with (LORAN actually, and then moved to..) off book reverse engineering of the OG NavStar format. To this day it's still "raw" GPS packets that are logged - and later post processed for greater accuracy (and often blended with a local area fixed position base stations "corrections" for GPS fix wobble).

There's a lot of fiddly pedantic stuff that goes with scientific data recording, timekeeping is but one domain of possible issues.

‹looks around from saskatchewan, hoping that this is the moment the rest of the world realizes that dst is also a stupid and wasteful hassle.›

Lots of places have gone "Actually this seems like a bad idea". Not too much has actually happend about it, that's trickier.

> I mean we deal with daylight saving time all the time

And I wish we didn't every year!

The real problem is they made Unix time non-monotonic. So there is no agreed universal monotonic clock.

We also don't deal with DST very well either. You won't believe the amount of programs written that treat local time as monotonic. It causes all kinds of problems and most people roll their eyes when someone who knows pipes up about local time and time zones etc.

It's not solving a very important problem and the edge cases it introduces makes software more complex and bug prone

If the world weren't entirely reliant on software to the extent it is today (like when leap seconds were introduced in the 70s), it wouldn't matter as much.