On a phone (which also acts as a wrist watch for most people), yes. Laptop, just no.
What OS does this? And how?
I think it's pretty safe to say most people want their laptop's clock to match their local time, because how is a wrong clock useful? Of course, if you're travelling for business with complicated schedules and meetings in home times, you clearly might have different needs, but most people just want their clocks to be right.
And you certainly don't want to keep your original timezone but change the clock setting -- then just everything's wrong! :)
And it is moronic for the OS to do this change behind my back (I don't know how OS X present this but thankfully Windows 7 doesn't do this madness by default).
How do I know that my OS got the time right? (did it perhaps get the time from my VPN location? was the network I connected to badly configured?) Since a laptop isn't connected to the net at all times I also have to consciously be aware of whether I've even been connected yet in this particular time zone.
"How do I know that my OS got the time right?" Well, have a look. I've often changed the DST switch manually after noting it not being correct. It wasn't then overridden by the OS "knowing better".
So, I have never ever (after the OS installation) changed the time zone for any of my computers and knowing that the OS doesn't do this behind my back I've never had to look or worry about it.
But even if it were perfect, why would you want your laptop to reflect the time zone you are currently in? Shouldn't the time on your laptop be the time you are the most familiar with and that you most deal with? For your day-to-day needs you have your phone and/or watch anyway, if anything a reference to the home time would be preferable instead of having all devices say the same thing.
This touches on to the relevant point of DST. I no longer have to worry about changing clocks; the worry has been replaced by the confusion over whether all my clocks have changed or none have.
At a bare minimum I'd expect any change of time zone to prompt the user.
Especially when you set the alarm for the next morning - and you know that DST kicks in but you have no way of knowing whether your phone knows that. And you can't change time beforehand because you don't know whether the phone will respect that or change the time back or make the change twice...
I found out that the stock android alarm app solves this (somewhat), when an alarm is set a notification tells you how many hours (and minutes) remain until the alarm goes off and this takes DST changes into account so you can see that it got it right.
Apple has succeeded in getting this wrong several years in row with the iPhone, quite embarrassing - and made much worse by the fact that you as a user can not prepare for it.
And for the record, OS X does it by sniffing for wifi access points. The particular access points available at any given location is a pretty reliable means of tracking location, assuming that there are any (if there are no access points, it can't find your location, and therefore won't touch your clock). The only exception are access points that themselves move, e.g. wifi on planes. I would assume that these access points are disregarded.
This is the same system that iOS uses to enhance the GPS (especially on iPod Touches and Wifi iPads, where you have no cell towers).
This is the part that scares me and has gotten me into trouble in the past. Basically it means I do not know if my clock is local time, home time, time of the last timezone I visited or something random and thus I cannot trust it.
This isn't just a hypothetical, but has bitten me in the past. Fortunately it lead to me showing up for my train an hour too early rather than an hour too late. But after that I never let my OS play around with my timezone settings.
Phone, yes.
Laptop, yes. Times are still stored internally, and the timezone represents a localization. And if I go across the world for the weekend I see that locally, it is UTC+10, while entries in a DB are timestamped accordingly. Then I return home and I can look at the clock in my menu bar and see my local UTC-8, and all the while entries in a DB are timestamped accordingly.
I'd love to hear your use case for "if location and correct timezone can be reliably determined, it still should not be adjusted".
Why do I say this? There are very few use cases I can think of - though I'm happy to be educated otherwise - for doing this differently. In addition, Outlook and Calendar on my Mac both pick up TZ changes and automatically re-render my calendar appropriately.
I really struggle to picture a use case of "I fly from my home in Seattle back to Australia, and yet I want the clock on my menu bar to display a wall-time 18 hours behind my current location, rather than displaying the current time where my eyeballs are at, and changing back upon return".
Actually, I can think of one - the fear that poorly programmed or tested applications may handle this incorrectly. In which case I can understand this desire, even as a facet of "solving the wrong problem"/shooting the messenger.
Would these be the same studies that Microsoft cites to justify force-feeding Metro to desktop users?