You have forgotten the shape of Norway. To drive from Lindesnes Fyr in the absolute south, to Kirkenes in the North East, while keeping on Norwegian roads the entire time is a distance of 2788km (1732 miles).
If we go via Sweden and Finland, this is cut down to 2310km (1435 miles).
Someone else posted a nice overlay map showing how Norway overlays onto the US.
The second point is that the country is rather cold during the winter.
We're also a rather sparsely populated country. Someone claimed that all major cities were within 150 miles of Oslo (except TromsÃ). This is also incorrect.
Oslo - Kristiansand: 356km (221 miles) Oslo - Stavanger: 556km (345 miles) Oslo - Bergen: 466km (277 miles) Oslo - Trondheim: 495km (307 miles) Oslo - BodÃ: 1202km (746 miles) Oslo - TromsÃ: 1739km (1080 miles) Oslo - Hammerfest: 1864km (1158 miles) Oslo - Kirkenes: 2310km (1435 miles)
It can of course be argued that BodÃ, Hammerfest and Kirkenes isn't major cities, but they're quite important.
It's quite true that we're mainly Hydropowered, but that isn't the only relevant bit. Electric cars are far more efficient than ICE cars. More of the energy goes straight into moving the car. Furthermore, fossile power plants are far more efficient than ICE engines. Even with electricity conversion losses - you get far more mileage per unit of fossil fuel from a power plant, than from a combustion engine for a car.
And finally, with regards to it being more polluting to produce the batteries for the EV cars than producing a ICE car - remember that you don't need to dig the materials out of the ground every time to get the so called "rare earth elements". You recycle, cheaply. When we've produced enough batteries once over, 95% of the materials can be recycled and used for new cars. Thus - we have a huge "one time fee" to get the materials, then we only need to keep producing about 5% of them to keep going. Which is very nice indeed.
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
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.
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 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'.
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.;)
Unixtime should not ever be modified. Same reason it should not ever follow daylight savings. Unixtime is absolute. It has to work on all planets and in space
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".
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?
Saudis, Guzzetti, Branco, Pinochet, Chiang, Batista, Battalion, Suharto, the Shah, Saddam Hussein, Vang Pao, Somosa, Mobutu.. just a small list of dictators supported by the US.
CO2 (based on released grams per kilometer): 0-75g: 0NOK 76-100g: 914.7NOK/(g/km) 101-130g: 955.49NOK/(g/km) 131-200g: 2685.98NOK/(g/km) > 200g: 3449.8NOK/(g/km)
NOX: 70.94NOK per mg/km
You add these together to find your engangsavgift.
The tax easily runs to more than 100.000USD for land rovers.
I'm in the same boat. I've tried teaching myself this technique, but fail every time. I can't remember the "familiar place", and I can't call up vivid imagery when I close my eyes.
.. and I never got to see it, only the sign that remains. Namely the building that hosted the Shockley Semiconductor Laboratory. The lab that basically started Silicon Valley.
Uhh. When you start something new, you come up with a prediction. You don't necessarily base it on that much information.
Then you observe what happens when you do an experiment. Then you adjust your predictions.
This is how basic science is done. Nothing new here.
HOWEVER; what you're trying to do, is transfer errors in initial prediction into errors in observation and measurements. That is rather disingenuous of you. Please do argue honestly.
Norway gets its electricity from hydropower. We started building out hydropower long before we found oil. Yes, we export oil. We're also an exporter of clean hydropower.
Slashdot Mirror
Norwegian Tesla owner here ..
I was out driving in less than -20C here in Norway this winter, so that bit is patently false.
There's plenty of chargers.
Norway might be small area wise, but length wise (south to north) .. think San Diego to Vancouver.
You have forgotten the shape of Norway. To drive from Lindesnes Fyr in the absolute south, to Kirkenes in the North East, while keeping on Norwegian roads the entire time is a distance of 2788km (1732 miles).
If we go via Sweden and Finland, this is cut down to 2310km (1435 miles).
Someone else posted a nice overlay map showing how Norway overlays onto the US.
The second point is that the country is rather cold during the winter.
We're also a rather sparsely populated country. Someone claimed that all major cities were within 150 miles of Oslo (except TromsÃ). This is also incorrect.
Oslo - Kristiansand: 356km (221 miles)
Oslo - Stavanger: 556km (345 miles)
Oslo - Bergen: 466km (277 miles)
Oslo - Trondheim: 495km (307 miles)
Oslo - BodÃ: 1202km (746 miles)
Oslo - TromsÃ: 1739km (1080 miles)
Oslo - Hammerfest: 1864km (1158 miles)
Oslo - Kirkenes: 2310km (1435 miles)
It can of course be argued that BodÃ, Hammerfest and Kirkenes isn't major cities, but they're quite important.
It's quite true that we're mainly Hydropowered, but that isn't the only relevant bit. Electric cars are far more efficient than ICE cars. More of the energy goes straight into moving the car. Furthermore, fossile power plants are far more efficient than ICE engines. Even with electricity conversion losses - you get far more mileage per unit of fossil fuel from a power plant, than from a combustion engine for a car.
And finally, with regards to it being more polluting to produce the batteries for the EV cars than producing a ICE car - remember that you don't need to dig the materials out of the ground every time to get the so called "rare earth elements". You recycle, cheaply. When we've produced enough batteries once over, 95% of the materials can be recycled and used for new cars. Thus - we have a huge "one time fee" to get the materials, then we only need to keep producing about 5% of them to keep going. Which is very nice indeed.
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. :-)
The only clarification I would make is UTC is, by definition, a timescale with leap seconds removed
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. ;)
Unixtime should not ever be modified. Same reason it should not ever follow daylight savings. Unixtime is absolute. It has to work on all planets and in space
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.
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?
Saudis, Guzzetti, Branco, Pinochet, Chiang, Batista, Battalion, Suharto, the Shah, Saddam Hussein, Vang Pao, Somosa, Mobutu .. just a small list of dictators supported by the US.
The tax is not the same for all fossil cars. Where on earth do you have that from?
There's 3 parts of the "engangsavgift" (one time tax, paid as you buy it):
Weight:
351-1200kg: 26.51NOK/kg
1201-1400kg: 66.05NOK/kg
1401-1500kg: 206.41NOK/kg
> 1500kg: 240.06NOK/kg
CO2 (based on released grams per kilometer):
0-75g: 0NOK
76-100g: 914.7NOK/(g/km)
101-130g: 955.49NOK/(g/km)
131-200g: 2685.98NOK/(g/km)
> 200g: 3449.8NOK/(g/km)
NOX:
70.94NOK per mg/km
You add these together to find your engangsavgift.
The tax easily runs to more than 100.000USD for land rovers.
I find it amusing that 53032 is considered a low user id these days. Mine certainly isn't very low.
I'm in the same boat. I've tried teaching myself this technique, but fail every time. I can't remember the "familiar place", and I can't call up vivid imagery when I close my eyes.
There was a writeup on Aphantasia making the rounds a while ago: https://www.facebook.com/notes...
It's quite a good read. :-)
.. and I never got to see it, only the sign that remains. Namely the building that hosted the Shockley Semiconductor Laboratory. The lab that basically started Silicon Valley.
https://en.wikipedia.org/wiki/...
It was located at 391 San Antonio Road, Mountain View, California. Now all that remains is a signpost.
Rather curious how the best app for end-to-end security is missing - namely Telegram.
Uhh. When you start something new, you come up with a prediction. You don't necessarily base it on that much information.
Then you observe what happens when you do an experiment. Then you adjust your predictions.
This is how basic science is done. Nothing new here.
HOWEVER; what you're trying to do, is transfer errors in initial prediction into errors in observation and measurements. That is rather disingenuous of you. Please do argue honestly.
You're funny.
Norway gets its electricity from hydropower. We started building out hydropower long before we found oil. Yes, we export oil. We're also an exporter of clean hydropower.