alt Hacker NewsHeh, 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? :)
Replies
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).
‹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.›
> I mean we deal with daylight saving time all the time
And I wish we didn't every year!