One of the most confusing things ever invented is time zones. Well, they aren’t inherently confusing by themselves but when you start talking about different time zones and daylight savings, then things get messy. Add in a factor of government zeal and you have daylight savings that can change dates depending on the laws and years that pass.
Microsoft has struggled with this for years with fairly regular updates based on regional changes. As you probably already know, the US has changed the default dates this year in an attempt to save energy.
Obviously computers don’t care much about time zones themselves but obviously the applications and users do. If the time zone is wrong then the time is wrong and all kinds of other bad things can happen from there. Sometimes it is not obvious that it is the time zone settings that are incorrect.
Regardless of all this fanfare, time zones are usually right and do provide a useful service to the user. When Windows correctly adjusts the time for daylight or standard times, it is actually a bit handy.
From a Citrix point of view, we had a new problem. What if the client and server time zones do not match? If a user logs into a Presentation Server, which time zone is he or she going to see? In the old days, the user would get the server time zone and would just have to put up with it. Around the year 2000, Citrix added support for using the time zone of the client on the server. The enabled the user to see their time zone being used for all the applications on the server. This includes applications that are time aware like Outlook to be able to display the meeting times in the correct local (user) time.
How was this accomplished? Basically the client started to send its time zone information to the server during initialization. Once the server starts the session, WFSHELL loads TZUSER which then starts the process of getting the client time zone and then configuring TZHOOK to actually change the time zone for that session. TZHOOK, as it sounds, hooks the time zone API and reports the client time zone information instead of the server’s time zone. This way, the applications things it is asking Windows for the native time zone information when really it is coming from the client.
The Presentation Server time zone support also supports clients that might not have the built in support for time zones. It does estimation based on the client time. It also has a policy defined that turns off time zone support if desired.
In PortICA we have a very different model. Because we are a single user system, we can get away with changing the real time zone during the session. This gets rid of the need to fool applications with the hook since it is already embedded with Windows with the server and client time zone matching. We do not match the time itself. This approach greatly simplifies the code which now really just to worry about saving and restoring the “real” time zone for the machine.
By the way, the time zone support does not use a virtual channel. The information about the client time zone is embedded in the standard information used during the initial exchange between client and server. Also, on PortICA, the PICASHELL component is responsible for loading TZUSER and there is no TZHOOK to process.
Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide
Red Circle Blog 
Jeff,
Nice write up. Good to see this is being well thought out for PortIca.
Thanks for the information, i was looking of the same as i had one client in USA and one in NZ and Citrix server has NZ time zone.
[…] Support. For those of you that haven’t read about Citrix Time Zone Support, please look at my previous post. The idea is to preserve the user’s local time zone while working on a potentially very […]