Hacker News Reader

Comment by fuoqi | Hacker News Reader

Computer systems (most importantly, UNIX) should've been using TAI [0] from the beginning. Human-readable time in turn should be computed from it using periodically updated time zones database which would include offset between TAI and UTC. By eliminating leap seconds we effectively re-invented TAI with a weird offset. While I am in favor of eliminating leap seconds as a hacky way to fix the current mess, it's sad to see that we added yet another quirk to the already complicated system of datetime keeping.

[0]: https://en.wikipedia.org/wiki/International_Atomic_Time

View on HN

No, they should not.

We convert timestamps to and from date+times all the time. Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that. Leap second smearing will ensure smooth and continious time.

Taking leap seconds into account is only needed in a very, very few contexts - maybe astronomy, or certain kinds of high-speed physics? Those rare users should be able to figure stuff out.

Go with UTC, don't optimize for rare usecases at the expense of everyone else.

You clearly do not know how much havoc and complexity leap seconds introduce into various systems. This is why leap seconds are likely to be phased-out [0]. It's effectively an admission that use of leap seconds in the "base" time was a mistake.

>We convert timestamps to and from date+times all the time.

If you do not account for time zones during this conversion, then you are not qualified to implement such conversions.

It's fine to use 86400 seconds for durations (e.g. "this computation will finish in 1d 8h 20m 34s"), but it's absolutely not fine to use it while dealing with datetimes.

[0]: https://en.wikipedia.org/wiki/Leap_second#Phase-out_and_futu...

>Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that.

Making an assumption that a day 86400 seconds breaks at least twice a year in many parts of the world, and that's before we introduce leap seconds or possibility of your code running on hardware that itself travels across timezones.

Timezones have nothing to do with UTC or unix time. Timezones only come into play when you convert between to other timezones.

Sure; but I happen to be one of the dozens of people who do not live in UTC.

So you have to do the conversion at some point _anyway_.

If your app presents me data making the assumption that _my_ day is always 86400s, it will be _wrong_.

You do not have to do the conversion. It is just for presentation for you and the users. You do not have to read or know anything about TZ.

Do you consider implementing filters like “filter these items to those that have happened in a given day/week/month” a “presentation issue” too?

Because you need TZ awareness to implement that in a way that most humans expect.

I've implemented exactly the filter you're describing. Yes, it's essentially a presentation issue.

There are 2 common ways to represent time: something akin to Unix time, which is just a scalar number representing the offset from some global reference instant (the epoch), or as "clock-calendar parameters" i.e. year-month-day-hour-minute-second. It's much more natural for software to operate entirely on the former representation right up to the point that the timestamps need to be either displayed as an output string for a human to read, or parsed from an input string from a human. Then you crack open tzdata [1] to do the conversion.

[1]: https://en.wikipedia.org/wiki/Tz_database

I think if your definition of "presentation" includes "parsing"; then we have very diverging definitions; but at least I understand we're mostly on the same page.

I programmed systems with both for many years -- the thing that needs to be defined early is whether your time an Instant or a Date/TimeOfDay/Quarter (collectively Naked)

Instant would be like log entry timestamp. Can be represented as unix time or SQL Timestamp.

Naked would be a "contract effective date" or "employment first day" or "invoice date" or "store opening time". Do not try to use an Instant to store it (e.g. timestamp at midnight to represent a day) or you're about to have a bad time later.

Instants are more prevalent in systems engineering, Nakeds -- in applications.

Only when you need to present the Instants to the user you need to convert them to strings and timezones come into play. Nakeds rarely need to be translated to Instants (e.g. when deciding if an invoice is overdue and send a email notification).

> live in UTC

Technically, nobody lives in "UTC". You might say people live in UTC+0, which is a standard time zone around the prime meridian. UTC refers to the system of standard time zones, not a single time zone, but in common speech "UTC" is often understood to mean UTC+0.

Let's say you live in California. During the winter, you observe PST ("standard time"), which is UTC-8. During the summer, you probably observe PDT ("daylight time"), which is UTC-7. Switching between the two is sort of outside the scope of the UTC system. It happens locally and is subject to local social and political preferences. Digital clocks mostly just keep track of standard time and possibly adjust their output if presenting a human-readable timestamp string.

Leap seconds are very much inside the scope of UTC. A leap second occurs globally for every standard time zone at the exact same global instant. It's determined by an objective criterion based on UT1.

Your message contradicts itself. Firstly it says leap seconds should not be used (aka TAI). But at the last sentence it says "go with UTC" (which has leap seconds).

We should have 60 seconds per minute, and 60 minutes per hour, and 24 hours per day.

How is this achieved - no leap seconds, smeared leap seconds, hard time jump every few thousands years - does not really matter.

> hard time jump every few thousands years

This is never going to happen. If handling 1 leap second every year or two is so hard and destructive, imagine the anxiety of introducing 30 all at once after 100 years of complacent software development with very few people alive who even remember the last adjustment. Of course our children will just say "screw that".

TAI always has 86400-second days. UTC can have 86401 (or 86399 theoretically, but that's never happened in practice). Eliminating leap seconds from UTC is so dumb because TAI already exists and is basically just UTC but without leap seconds. But, for some reason, the BIPM would rather allow UTC to drift from UT1, but it will always have the ~40 historical historical leap seconds that have already occurred. It will become a strictly weirder version of TAI.

I predict that in hundreds of years, as UTC-UT1 reaches several minutes, people will start talking about inventing a "new" time keeping standard with leap seconds to stay in sync with the Earth, and shift to using that for civil time keeping instead of drifty UTC. Then we'll finally be where we should have been the whole time: effectively using TAI as the source of truth, and converting to civil time by introducing leap seconds (but the new "TAI" will be weirder than the old TAI, which we should've just been using the whole time).

I wish I could upvote this more. I've done so much timestamp work and this is the hill I was born to die on.

Huh, that's an interesting point. Not sure I agree though. I always was irritated by the complaint that leap seconds are complicated and must be eliminated, and I am convinced that eliminating them in UTC is the most idiotic decision ever made, and I sincerely hate the idiots who made it, but, indeed, the idea that UTC time is just a time-zone representation of linear TAI time on Earth does make a lot of sense. On the other hand, we still can convert between UTC and TAI, so treating TAI as primary only makes sense if it clearly would make things simpler. And it's very unclear if it would. It really seems like the "correct" abstraction, but the problem is that currently my main hack for avoiding time complexity is always using datetimes in UTC+0 internally, thus ignoring time zones until I need to display something for user. This way I know that 14:00 today + one month is still 14:00 in my "internal" time format, even if in the user TZ one is DST and the other one is not. And a hundred of other ugly things I am willing to ignore in practice. And in 99.999% of cases I don't even care how many days are in that month, let alone seconds.

Now, if I cannot really add a month anymore (and I cannot in TAI, because months don't even really exist in TAI, since TAI isn't a solar year) in my internal time format, all that convenience goes away. I now must always worry about leap seconds and timezones and all the stuff I don't really need to think about in the vast majority of cases.

…Yeah, well, I'm really not sure. I am not convinced, and am honestly kinda relieved by the fact I won't have to find out. But it's an interesting point nevertheless. And, no, UTC w/o leap seconds is not the same thing. In fact, UTC w/o leap seconds is kinda the polar opposite: it's clearly the wrong abstraction, because it ignores the (not even so hard) problem somebody doesn't want to deal with, which doesn't really go away, but is very practical.

> This way I know that 14:00 today + one month is still 14:00 in my "internal" time format

Unless there's a leap second in that month. Then it would be 13:59. Maybe you don't care, but some people do. It could have legal or technical ramifications.

> Now, if I cannot really add a month anymore (and I cannot in TAI, because months don't even really exist in TAI, since TAI isn't a solar year).

What do you mean by month? Calendar months are obviously irregular (thanks February). "30 days" makes perfect sense in TAI. Indeed, 14:00 today + 30 days would always be 14:00 in TAI.

Reply on news.ycombinator.com