Hmm.. don't think so.. NTP and NT5DS protocols don't deal with time zones, just time. My laptop is set for EST/EDT, but if I travel to our site in Australia and sync with the local DC there, it will still display EST/EDT time (and quite accurately, too, since I'm syncing to a local authoritative time source!) We have a highly accurate time environment here, using NTP on all servers and the PDCe, NT5DS on the other DCs and workstations. Our retail locations throughout all of North America sync to DCs in the NYC metro area, and all have locally defined timezone settings.
Now that the OP has clarified that it is a travelling laptop that needs to adjust to a different, local time zone, the challenge becomes clear. You need to have some way to identify that the network location is a different time zone.
You can't simply query the DC because the site you're at might not have one, or you could authenticate to your "home" DC.
AD Sites might work, but they might not be configured, or might span a timezone border. Subnets, however would rarely (ok, prolly never!) cross a timezone border. (imagine the grief of a business office split by a time zone! 
)
So, assuming that you could create a translation between subnet ranges and timezones, you could potentially update the timezone setting during logon. However, since timezone is a machine and not a user setting, I'm thinking that it won't be as simple as plugging values into the registry. Might need a reboot or minimally a restart of the W32time service - not sure. Of course, if those actions are needed, the code would have to be smart enough to trigger them only if it actually changed the timezone value.
Glenn
_________________________
Actually I
am a Rocket Scientist!
