I Know This Is A Totally Random Thought :l But..

[Doctordick]

Your watch picks up an external signal. Computers cannot be assumed to be able to pick up an external signal so the programmers writing the clock software cannot assume that the computer will be able to receive an external signal. Your argument holds no water.

 

Ok, so they can't pick up that colorado signal. That wasn't the issue I was talking about. My wife and I often go off to places where my watch can't receive that signal either but the programing in the watch still works. I can always set the watch by hand. If down the road it receives what is a more dependable setting from somewhere, it can and does change (I suspect the actual time set is always colorado time as time zones are directly changeable). The point is that no matter how the time on a device is set the actual device should be set to a standard which as CraigD says can generally be obtained somehow

 

My main complaint with Buffy's answer was the comment as to why reason why most computers today still do not come out of the box set up to sync to an internet time server. In my opinion they should be set with some "set time parameter" which could be fixed to some standard source. The standard source could then provide the associated information required. In my opinion they don't have such a standardizing thing because programers are not interested in providing it - period.

 

Have fun -- Dick 

[Eclogite]

In my opinion they don't have such a standardizing thing because programers are not interested in providing it - period.

I often wonder if the number of opinions in the world outnumber the number of facts and if so what this says about our critical thinking.

[Buffy]

Hi Dick!

 

My main complaint with Buffy's answer was the comment as to why reason why most computers today still do not come out of the box set up to sync to an internet time server. In my opinion they should be set with some "set time parameter" which could be fixed to some standard source. The standard source could then provide the associated information required. In my opinion they don't have such a standardizing thing because programers are not interested in providing it - period.

 

That question is of course not the same one as in the OP, which is why computers don't change their time generically, not when the box is opened.

 

Now in fact Windows and MacOS both do the "out of the box" thing when you first turn it on, but ONLY if you've got an internet connection. They do typically try to sync if they can find a time site, and actually have a setting that lets you have the OS regularly check the time, but it still assumes it's been told what the time zone is, because the system cannot figure that out on it's own. As Craig mentions above, the cell phone networks know exactly what cell antennas you're connecting to and the exact time zone that the phone is in based on that, so you never ever have to touch anything about the time setting on the phone (fun home experiment: find a place to go where you cross a timezone and watch the time on your phone change as you cross the time zone border!).

 

There ain't no similar thing for a generic internet connection. While there are some geolocation databases for ip addresses, they are notoriously inaccurate (in my previous abode, the city I got geolocated in was over 65 miles away from me), and because IP blocks are bought and sold, these databases can be in completely different hemispheres (some of the spammers who try to pollute Hypography have IP addresses that geolocate as "US", but that have been sold to places like Khazakhstan...). 

 

So the bottom line on this for those of us who travel a lot is that we do have to reset our time zones on our laptops all the time, even though our phones know exactly where we are.

 

This also causes fascinating programming problems for developers building scheduling software where If you're in Los Angeles and schedule a conference call for Noon Pacific time and then get in an airplane and fly to New York, is you're scheduing software smart enough to realize that not only are YOU in New York at 3PM but the call is still set for Noon Pacific. I'll leave that as an exercise for the reader, with the simple note that the answer is not simple....

 

Now between time zones and the fact that error handling of internet connections is fraught with peril (sometimes even the best network drivers will manage to hang your machine if a program improperly tries to reach a network address, especially if you're behind a complicated firewall), and as a result, even the operating system authors are loathe to try to maintain that syncing with a time source, unless you explicitly configure the system to do so. You need to consider the problem that this would need to be done not just at start up where the OS is running in a more completely locked down state where error recovery is easier, but also when people put their laptops to sleep and awaken them again.

 

Then of course there are more and more places (used to be just government, but with Sony and other hack attacks getting bigger, now most large corporations) that are locking down their internet connections and considering the fact that spoofing is a real risk, are locking down their firewalls to access to the live time sites. 

 

So, with all these complications, trying to fix what is really a basic missing piece of the TCP/IP networking protocol with ugly kluges involving trying to find out where someone actually is along with trying to reach possibly unreliable time sources that may be blocked, what we have is a software problem that developers usually term "non-trivial."

 

There are fixes that could be made to TCP/IP, but they are fraught with peril because they increase interdependency among the actors in a network whose very architectural strength is the fact that there is little interdependency. There are folks who value secrecy (includinging primarily governments, not just hackers or paranoid individuals) who actually want to make sure that TCP/IP *can't* betray their location easily, and since those groups have the greatest influence on what gets added to the standard, we're unlikely to see a resolution to this problem soon.

 

So the bottom line is: if you want your time updated, it's likely it already is syncing and you don't even know it, although if you work in a big company it probably is NOT, and if you move your location you're on your own.

 

And no, it's not because we developers are "lazy."

 

 

To find a fault is easy; to do better may be difficult, :phones:

Buffy

[pgrmdave]

This also causes fascinating programming problems for developers building scheduling software where If you're in Los Angeles and schedule a conference call for Noon Pacific time and then get in an airplane and fly to New York, is you're scheduling software smart enough to realize that not only are YOU in New York at 3PM but the call is still set for Noon Pacific. I'll leave that as an exercise for the reader, with the simple note that the answer is not simple....

Is it not as simple as using UTC? No matter where you are, the UTC will be the same, so crossing timezones won't matter.

[Buffy]

Is it not as simple as using UTC? No matter where you are, the UTC will be the same, so crossing timezones won't matter.

 

Absolutely use UTC! But the problem is still in getting your own timezone right (not to speak of converting it properly both on input and output): You don't know how many sales people I've run into that work on the west coast, have their laptop set for the east coast (the default in too much US-built software), and just keep the time shifted 3 hours... A more practical issue that comes up is people talking on the phone with those in other timezones and just plain forgetting about the time shifts. I've written software that uses UTC, but has to provide all kinds of time zone cues to people when they move around or communicate with people...and then they complain that it's "too complicated." 

 

 

Do what you know and perception is converted into character, :phones:

Buffy