| The Time Zone Clock Assignment | |||||||||
|
My Answer to the Assignment from the Chapter 7 lesson |
|||||||||
In the lesson for Chapter 7, there was an assignment to create a Time Zone Clock that looked like this: There are a variety of different ways that this might be done. The simplest way might be to use InStr function in VB.NET to find the 'hours' part of the time and add or subtract from it. But then you would have to know which time zone the program is running in and how many time zones away the three other zones selected by the RadioButton components are. You would have to worry about exceeding 24 hours or displaying a time less than zero. (VB.NET can't accomplish time travel ... yet.) In short, there's more to this than meets the eye. Sorry for giving you such a tough assignment ... but look at how much you learned while you were working on it!!! Microsoft even admits that this is a tough nut to crack! At the Microsoft sponsored site, gotdotnet, they say: Does the .NET Framework support Time Zone conversions to any given Time Zone? Not in V1.0, V1.1 or the Whidbey pre-release. The .NET Framework does support conversion to and from UTC and the systems current local time. It can also support parsing a DateTime from an arbitrary time zone offset, such as 2003-10-26T13:11:07+10:00, but it must always convert this either to Local or UTC. This is a very common feature request and is likely to be in a future version. People are often surprised why this feature cannot be supplied by Microsoft at low cost. In particular, data to do conversions exists in the Windows registry and is used by the time zone selection dialog. However, there is a big distinction between having UI and registry data and having an API. This is a more expensive feature to undertake for Microsoft than most people would imagine because (a) an API must provide consistent behavior from one machine to another so we cant just re-expose the registry data and (b) there is cost for Microsoft in exposing an official Time Zone conversion because we face on-going geo-political costs for any country/region based data we gather and maintain. For example, a country may threaten to boycott our product if they are not listed in the data. This has happened to us with our CultureInfo data on many occasions, and we often need to tweak data in service packs, which is expensive and risky. That being said, there is agreement that this is a very important feature, and it is under serious consideration for the WinFx release. Even Microsoft has trouble with international relationships! But, considering the other problems, using the .NET Framework objects to solve the problem is still the "way to go". The key class that supports this in the .NET Framework is the TimeZone class. This class has a method that allows you to convert the time at a local timezone (whatever it is) to UTC time. That takes care of the first RadioButton. It's not a perfect solution (it doesn't take into account daylight savings time, for example) but a fairly adequate way to adjust UTC time for the other two time zones is to use the AddHours method available for the DateTime datatype. After this, just format the time with the ToShortTimeString method and, as they say in Britain, "Bob's your uncle!" There are certainly more sophisticated ways to do it (again using the .NET Framework) but this one seemed to me to get nearly all of the job done without being really complicated. Here's the code: |
|||||||||

