A lot of us drive EVs. About 50% of new cars sold are EVs.

I'm not sure what you mean with "It doesn't do another second at the same value"? Unix absolutely does another second at the same value.

Let me illustrate:
Let's assume we're at December 31st, at 23:59:59. Unixtime in seconds would then be: 1483228799

The milliseconds count, in increments of 250ms each, would be:
1483228799.000
1483228799.250
1483228799.500
1483228799.750
1483228799.000
1483228799.250
1483228799.500
1483228799.750

that's right, the counter jumps back 1 second.

What epoch time are you referring to? You're certainly not referring to unixtime, which tracks seconds since the unix epoch. Minus the leapseconds which it doesn't do right.

You are sort of correct. The problem is that most webservers run unix, and unix doesn't count second since UTC epoch. Heck. It doesn't count seconds since unix epoch.

Leapseconds aren't representable in unix time.

In any case; I think I agree with 100% of the premise of with the main body of your argument. I keep using GPS time and TAI interchangably, even though there are differences. GPS time is attempted to be kept in sync with the theoretical TAI regularly (once a day or so?).

When it comes to implementation, we might disagree. But I do believe we agree about the facts. :-)

I believe you to be wrong, or that I'm misunderstanding you.

UTC including leapseconds were adopted in 1970 and implemented in 1972.

It is, however, impossible to calculate the seconds between two UTC timestamps, without consulting a table containing the leap seconds in between.

I'm wondering if you're thinking of UT1 when you write UTC?

I don't have a good answer for you. I'll give you my opinion and that's that.

Given that we only drift a tiny amount (about an hour per 5000-6000 years), and given that we keep redefining calendars, time, timezones and so forth way more often than this .. I'm fine with a system that slowly drifts away. We can readjust it later. Either when we get really good at calculating all future leap seconds, or whatever.

We've got the second defined by physical properties. Which is great. It's even exportable if we conquer the universe. Days will be measured in different amount of seconds than 86400. That's the approximate unit for earth. A mars-day would be different. Days on various moons would yet again be different. If we were to conquer other solar systems it would be different.

We could still keep a well defined second.

I personally am not worried about whether a 'day' drifts a bit. Especially since a day at the east end of a timezone is different from the 'west' end of a timezone. And of course, timezones typically follows various human made borders - which means the change from date to date doesn't match up with 'astronomical midnight'.

Funny.

The question here is "what's defective"?

Historically, a second was defined as 1/86400 of a day. It's a good definition. However, we've later decided that since that period isn't absolute, we should rather define the duration of a second.

So, in 1967 the second was defined to be exactly 9,192,631,770 times the period of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 atom.

Now, while that matches up "pretty well" with a day, it doesn't match exactly. The earth wobbles a bit, and is slowly being slowed down by tidal forces - but not in a predefinable way. We need to observe .. and when the difference makes the time we've tracked with atomic clocks be out of sync with the earth - we adjust time. We insert a leapsecond. By decree from a commitee.

Thus, we have TAI - which is atomic time - which is what we get from atomic clocks. This is out of sync with "earth time". Unix time is in sync with "earth time" but not with atomic time, and unfortunately isn't monotonically increasing time due to the way we hack around leapseconds with it.

Given this, we can claim that atomic time is defective because it doesn't track earth time. We can claim that earth time is defective because it's not always the same. Or we can claim that both are actually pretty darn OK, and that we should just sort out the differences in a coherent manner. Or that this isn't important enough that we shouldn't just stick with atomic time which makes everything easier for everyone except astronomers.

Now, you say "Do it once, do it right" about time. The great thing is that we have presedence in doing things slightly wrong. Take the gregorian calendar, which is the one we're using.

You know, every 4 years is a leap year, except if it's divisible by 100, then it's not. Except if it's divisible by 400 - then it is. This is to ensure that seasons stay reasonable stable. Right? Do you think this works out great over time? Well, it actually works out pretty great, but it does go off over time. We go off by a day for every 4000 years (way worse than my suggested 1 hour over 6000 yers! :P). There should be 969 leap says over 4000 years to be in sync. There is 970. Ooops. It hasn't been reformed, although Sir John Herschel proposed the change more than 100 years ago. It was apparently designed incompetently - if we're to follow your thinking. ;)

Get your facts straight. Unixtime doesn't work like that, and that is kind of the problem.

To illustrate this, in 2016 we had a leap second on Dec 31st. In other words, time went like this:

Sat Dec 31 23:59:59 UTC 2016
Sat Dec 31 23:59:60 UTC 2016
Sun Jan 1 00:00:00 UTC 2017

However, if look at this with unixtime, we get:

$ date --utc --date @1483228799 ; date --utc --date @1483228800
Sat Dec 31 23:59:59 UTC 2016
Sun Jan 1 00:00:00 UTC 2017

There is no way to represent the second that happened at Sat Dec 31 23:59:60 UTC 2016 . It doesn't exist in unixtime. You can't reference it, except by 1483228799 twice. That's right, in unixtime, that second goes to the end, then does another second at the same value (!) Two seconds happened in the real world, while the unix timestamp ticked twice.

So, your assertion that unixtime is absolute is unfortunately simply wrong. Unixtime doesn't do leapseconds. It doesn't work on all planets and in space as you describe. It's closely tied to UTC "but let's ignore that leapseconds exists".

I'm of two minds here;

With a system that keeps getting vendor updates, I do believe that /var/lib/leapseconds would be the right place.

However, given the plethora of very old systems around, I do believe it should be in a human configurable file. I would find it quite unnatural for sysadmins to go and inject leapseconds into a file in /var/lib. Echoing the "leapsecond timestamp" into /etc/leapseconds would, however, be entirely natural.

I can live with both, though - we're currently simply bikeshedding ;-)

The problem with Leap seconds is that they are really, really problematic under unix. Unixtime literally doesn't have leap seconds. There are hacks and workarounds, but only that.

There are only two real solutions:

1. Get rid of the concept of leap seconds. The earth's rotation will slowly drift out of sync with astronomical time - but only with about a minute per century. Let someone deal with a leap hour in 6000 years time. Having all of society deal with astronomers who don't want to keep track of this on their own is just silly.

2. Redefine unixtime to include leapseconds. Change the POSIX standard and all other relevant standards to have unix run on TAI instead of UTC. Keep an /etc/leapseconds where all leapseconds are inserted. Let the system time conversion libraries deal with the conversions authoratatively.

And don't get me started on the hackish fugliness of leap second smearing. Ye gods is that an ugly hack.

?? Why on earth would that be bullshit. By the age of 7 I had already started taking a stab at very simple programming (if, else, etc). I was annoyed that I couldn't copy games because I only had a single tape drive, and had to get friends with dual-casettedrive stereoes to copy games for me.

You get to a point of diminishing returns when it comes to typing speed. At a certain point you're limited by having to rephrase stuff. And if typing down what someone else has been saying, you're constantly thinking about how this would be written better than what has been said aloud.

At >600 chars/minute, I feel I'm well past the speed that is necessary to get things done.

A lot of us here on Slashdot aren't Americans, and in the world outside of the Soviet Republic of California, demand for Tesla is non-existent.

.. then ...

In places like Western Europe, where it is within financial reach of the affluent minority, the sales outside of the two countries that provide a significant subsidy are down sharply: linksnipped

.. let me just say that as a Norwegian, there's an insane amount of Teslas on the road here. One of them mine. Best car I've ever had.

Demand here is insane, and we need more service centers. :-)

This comes down to the resolution used. Think fractals. What's your minimum measurement unit? 10km? 1km? 100m? 10m? 1m? 10cm? 1cm? 1mm? Smaller?

The smaller the unit of measurement, the larger the coastline, as you can cover smaller and smaller details.

Then it's the question of where to place the coastline. High tide? Low tide? Middle? What about the "type of coastline"? It seems obvious if it's rock .. but what if it's sand? Where do you put the line?