[theamk]

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.

[deepsun]

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

[theamk]

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.

[bloppe]

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

[klausa]

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

[deepsun]

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

[klausa]

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

[bloppe]

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

[johnisgood]

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.

[klausa]

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.

[bloppe]

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

[fuoqi]

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