by Michael S. Kaplan, published on 2011/12/27 08:06 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/12/27/10251232.aspx
The other day, a colleague asked me a question that disturbed me:
Hi Michael,
I want our product to get out of the business of maintaining timezones and leave this up to the OS. However, I realized that the system only provides one language at a time, so if the administrator language is English and the end user’s language is French the time zone names would show up as English. Err. Do you know how other teams have solved this problem (without maintaining their own list of timezones)?
Thanks
Okay, there are a couple of problems here.
The huge push to bring time zone to the world of the Windows Multilingual User Interface, something I mentioned in pasing in Keyboards and time zones have something in common, is a huge and expansive architecture that gives you the ability to do quite a bit.
Now by default, a service running as LOCALSYSTEM is limited to one language.
But simple use of the EnumUILanuages function will give you a list of every single language for which resources are available. From there, you just have to set the process and/or thread UI language and then you can load up whatever you like -- thus a sever component communicating with clients can use SetProcessPreferredUILanguages or SetThreadPreferredUILanguages (as I discussed in New for Windows 7: The PROCESS to keep MUI from being THREADbare...).
And you can thereby get the appropriate strings for any language available -- mostly via the documented Win32 APIs for MUI and time zones that will give you almost everything you need (time zone enumeration itself still requires the registry which is nevertheless fully documented, but everything else has API coverage).
For earlier versions like Server 2003 I'm comfortable telling them to upgrade if they want the feature, and you should too! (a lot of engineering went into this, after all!)
Perhaps it feels burdensome to require UI languages be installed to get this feature, but this hardly seems like an undue burden to get the feature....
When I think about the original question, the part that worries me the most is that the act of "getting out of the business" implies that right now they are in the business, with one of the single most expensive items to maintain -- time zone data. The sheer weight of standards tracking and potential geopolitical issues with names and zone definitions? Maintaining them is staggering -- why would anyone want to duplicate that effort?
And how many features have had to be postponeed version after version that those resources could have been applied to?
I'm being facetious there, actually -- that effort currently is duplicated a bunch, and those resources are in fact wasted, many times over.
Though my hope is that soon after I send this link, there may be one less case of duplication on the horizon.... :-)
John Cowan on 27 Dec 2011 11:21 AM:
Good to hear. With time zones as many other things, the point is not to see who can pick the most potatoes, it's to get the *@#$ potatoes picked before the (@#$ frost hits.
referenced by