Fisker Buzz Forums banner

1 - 8 of 8 Posts

·
Registered
Joined
·
189 Posts
Discussion Starter · #1 ·
I am on 6.28, and found that I had to go into settings, and manually turn off daylight savings time setting - whereas my computers, iPad, etc adjusted automatically. Did anyone with the new software find that it automatically detected the date and set itself back an hour?

Not a big deal to do it manually, as the other cars I have required manual clock setting, but just curious since the Karma does have a "daylight savings time" setting, and time zones...
 

·
Super Moderator
Joined
·
1,183 Posts
I am on 6.28, and found that I had to go into settings, and manually turn off daylight savings time setting - whereas my computers, iPad, etc adjusted automatically. Did anyone with the new software find that it automatically detected the date and set itself back an hour?

Not a big deal to do it manually, as the other cars I have required manual clock setting, but just curious since the Karma does have a "daylight savings time" setting, and time zones...
I'm on the new 510 baseline software and I had to manually tell the car it was no longer DST. I didn't change the clock, I just set Daylight Saving Time to Off.

Brent
 

·
Premium Member
Joined
·
4,659 Posts
I have had several cars that set the time automatically fromt he GPS timebase but I still had to set the DST. You would think that the car could use the GPS to figure out where it is and set the correct time, DST and all. I think the car manufacturers are trying to give the user maximum flexibility on what time is displayed.
 

·
Registered
Joined
·
546 Posts
But it does seem that if you had DST turned 'on' in the settings, the car should figure out that the time has changed based on GPS location and set the clock back (or forward in the spring) at the appointed day/time, whereas if you had DST turned 'off' the clock would not change.

(And how great is it that this is the 'issue' we are moaning about?!)
 

·
Registered
Joined
·
913 Posts
I don't know which software they're using. If it's Linux it should be using the Olson TZ database which means they can get this right automatically, and in fact you should not have to have a "DST" setting at all, you just say "I'm in Phoenix AZ" and it knows you don't do DST, or you say "I'm in the Navajo Nation in AZ" and it knows that you do (this seems to surprise people a lot: in the summer, parts of AZ are an hour ahead of other parts because of this; then again, it surprises people that the rest of Arizona is sometimes on California time, and sometimes on Utah time).

In general, though, there's a problem: Daylight Saving goes on and off in unpredictable ways. If you're in Israel, for instance, it's the Knesset that determines when DST starts and ends, sometimes as late as just a few months before it may start or end.

What whoever is doing the software should do is have three settings for DST: "definitely on", "definitely off", and "automatic using the Olson data". The default should be "automatic". Then, if you're in a place like Israel—or sometimes, the US—where your database has not been or even cannot yet be updated to track the latest mad schemes of the ruling political body (Congress has proposed bizarre DST changes often, and even passed them occasionally), you can manually switch it.

I had assumed they were using the Olson DB, because the system offers you a choice of "nearest city" which is precisely how that stuff is labeled: in /usr/share/zoneinfo there are directories like America containing files whose names run from Adak and Anchorage through Denver and Los_Angeles and on to end with Yakutat and Yellowknife. Simply replace underscore with space and you have a fine list of choices (although you have to add location data to show it on a map the way the Karma does).

Then, if Congress go mad and suddenly decide that starting in 2016 DST will, but only on Presidential voting years, begin in February instead of April, go to "double DST" in June, switch to "half DST" in September and then go to "negative DST" on voting day in November, it's just a matter of editing the zoneinfo source files, running zic (the Zone Info Compiler), and installing the new /usr/share/zoneinfo database. Whether you live in a region covered by America/Los_Angeles or Asia/Singapore or Africa/Cairo or Pacific/Auckland, you'll get the updated files with the new bizarre USA-every-four-years rules. You can drive from America/La_Paz to America/Halifax and as long as you pick the right nearby city, it will know, even for the oddball half hour DST that Halifax uses. You can even drive from Australia to Hawaii, if you can figure out how to keep the car from submerging first. :D

(The funniest thing is, they probably are using the Olson DB, they just don't know how to use it. This turns out to be distressingly common.)
 

·
Registered
Joined
·
289 Posts
Good call about the Israel DST, they just approved today to change it in a different date then it was last year :)
 

·
Registered
Joined
·
913 Posts
Good call about the Israel DST, they just approved today to change it in a different date then it was last year :)
I didn't make up the "Pacific Presidential Time Zone" idea either: it got floated back in the 1980s or 1990s (I forget exactly when) because people in California, Alaska, Hawaii, etc., were complaining that the presidential election would get called before their polls closed. So, the idea was that once every four years, for some time near Voting Day, everyone sufficiently far west in the US would skew their clocks a bunch so that their voting times coincided with east-coast US voting times.

No matter how crazy you think some timekeeping idea may be, someone somewhere is probably trying to get it put into place. :D
 

·
Registered
Joined
·
192 Posts
Karma time

After reading several of these posts, I went to the garage to set the clock back one hour, only to find that the Fisker had done it for me. ???? :):)
 
1 - 8 of 8 Posts
Top