I think you're on the right track with using the built in TimeZoneInfo class. The ID should never change, but the name will (I learned that lesson the hard way when several changed between xp and vista). I have used a virtually identical approach (UTC only at the service and db layers, local time on the web server & client) and it worked just fine.
One thing I suggest is to wrap the various TimeZoneInfo methods you intend to use with an interface ITimeZoneConverter or something of that nature, that way if you need to change your implementation later, it should be easier to do.
Random Annoyance: The .Net TimeZoneInfo class can't give you an abbreviation given a timezone. IE: No "EST" for "Eastern Standard Time", so if you need that, plan on having a lookup into some sort of resource file or table for that.
Javascript won't actually be able to tell you the timezone, just the timezone offset from UTC. It's a subtle difference, and in your case it sounds like it won't matter, but it's something to keep in mind when looking at what timezones get assigned to your users.
I have seen some JS libraries such as this one which attempt to guess the timezone on the client side based on offset and most populated timezones. It is an interesting approach, but I don't know how well it would work in production.
Finally, one thing that bit me in the past was that JSON doesn't actually specify anything about how to format datetimes. (related reading) If you're doing a lot of ajax/async requests and intend to convert back and forth between utc & local times, this can be painful. Make sure you write some good common parsing/offsetting functions and make sure everyone on your team is aware of them and doesn't re-invent the wheel every time when dealing with these issues.
There is no way to tell WCF to kill a request that is underway. You would have to roll your own solution. For example, have another method on the WCF object that you can call telling it to cancel any operation currently underway.
You may want to re-architect your solution to support this. For example, when you start the big-data-retrieval function you could return immediately with a request-id. Then have periodic events that are sent back to the client from the WCF component with data collected so far and a "cancel" argument you can set to cancel the operation. Or have a method that the client can call to get data collected so far, passing in the request-id and provide a cancel method accepting the request-id.
Here is a similar question on SO: https://stackoverflow.com/questions/15324995/cancel-a-long-running-task-over-wcf-from-client
Best Answer
Check parapura's answer in this Question.
This approach is called long polling, its simple and should provide you the data you want whenever its available from the server side.
Check this Blog for more detailed sample class.