Notice how the above word "Problems" is plural. I don't know whether the engineers were high on something or what, but the Global Time function has oodles and oodles of screw-ups and so we end up with a mushed up, trompled on and spit out piece of "SHIT".
Sorry if that terminology offends some people, but believe me, I tried long and hard to find another way to describe it, but couldn't come up with a better word.
By the way, it stands for "Stupid Half Incomplete Trash". And MS's attempt to cover up the PROBLEMS worked fine at first, but it has now turned on them after problem #23 zillion. It makes them sound like they don't know what they are talking about because they contradict themselves, but we already know that anyway don't we!
Really, it's so screwed up I don't even know where to begin. I've tried documenting this several times but gave up each time because I was running in circles and couldn't come to a final conclusion other than "I wish the reader good luck" in trying to understand the situation. There are just so many things done wrong or different or contrary to what other documentation says that it's just one big maze, but I'll do my best to try and provide you with the strange "wierdisity" (don't bother looking it up because it's not in any dictionary... I just made it up because no other word seemed to fit) of the situation.
Listed below is information that I've gathered from all over Microsoft's web site and on-line reference manuals. The original content has not been modified, however, it has been reformatted with unnecessary portions removed for ease of reading and documenting in a unified format.
To start with, various terminology used in the explanation requires prior knowledge of various basic terms referenced throughout. (e.g. UTC, bias, standard bias, daylight bias, etc.)
therefore if you're not already familiar with the meaning of them, you might want to increase your knowledge base.
With this information under your belt, let's get into the nitty gritty.
First of all, the global timezone is initialy setup when you first install Windows NT on your machine. You can later change that setup from within the control panel. If your TZ environment is not properly set up for the timezone you are current in, you can run across the following problem(s):
Notice here, that the title says "if TZ Variable Not Defined" C run-time (CRT) functions, localtime() or ctime() will display the proper time, but Win32s does not display the correct time from a 32-bit application when the TZ environment variable is not set to zero.
Sound contradicting? Which part? The part where "Win32s and CRT disagree" if the TZ variable is not set... (not set to what?), or the double negative towards the end of the paragraph "does not...is not"?
What is the reference base here? Whether the TZ is set or not, or whether the proper time is returned or not depending on whether you use CRT or Win32s? Guess we'll need a Microsoft lawyer to weed through this one (pun intended). And this is one of the easier ones, that's why I picked it first. But think about what's been said, how do you NOT define the TZ Variable?
As mentioned above, the timezone is set when installing WinNT and the registry entries for setting the system's global clock must be set to something. It would only be set to "0" if you were on GMT (Greenwich Mean Time), so back to my original question, how do you NOT define the TZ Variable? It's always set to something. And it does have a default value of something. Even a "null" or blank usually takes on the numeric value of "0"!
Microsoft themselves have a default value as follows:
Although the title may seem a bit strange about Dir-Sync, I've used this reference because it clarifies (towards the bottom in red letters) what the default TZ setting will be if it is not defined as mentioned above.
Then comes the question of why Win32s would not be consistent/compatible with C run-time. If you think about it, it's rediculous in that if TZ is set to something other than "0", Win32s applications will show the incorrect global time, and if it is set to "0", then C run-time applications will show the incorrect global time. Either way, you're screwed... but isn't that Microsoft's daily chore... "screwing someone that is?" So Microsoft, after realizing this problem, had their tech support staff draft an explanation that this is per specification and not a Microsoft mistake and came out with a blurb that as TZ is normally set, that the C run-time library is correct and that any applications written for Win32s must declare the TZ=0 in the application variable as that application is being started up. I had the reference around somewhere, but think that I deleted it when I gave up on one of my attempts to document this problem.
And this is just for starters. It starts to get fun from here. Microsoft does not recognize all timezones in the world. They only recognize those listed in an RFC that dates back ages ago and blatantly states that if they were to support timezones not listed in that specification, that they would not be within specifications and that MicroSoft strives to be adhere to all specifications as best as they can. This reference as well as the one above was deleted in anger after giving up umpteen times trying to document this problem.
Now here's the hair banger... Japan, the country where I work and live is one of the countries that it does not support as per the above mentioned RFC. Due to this, when you install the WinNT Japanese version (or any WinNT for that matter) to run in the JST-9 (or Japan time) timezone, you can select Japan from the installation menu, but it will not display the proper Global Time (although the local time will display properly. If you look at the registry for where the Global Time variable is stored, you'll find "-28800" as the value stored. This is the amount of time (bias) from GMT (in seconds) that the current time zone is. Therefore -28800 seconds = -480 minutes or -8 hours. That puts you at GMT-8 or PST+8 which is Pacific Standard Time. This value should be +32400 seconds or +540 minutes or +9 hours.
Therefore if you want to perform a directory syncrhonization with Japan, or have SMTP or other mail packages which refer to the global time instead of local time show proper global time stamps, then you'll manually have to edit the registry yourself.
And now for the catcher...
What can I say...
Microsoft says that the problems can be fixed for any timezone, but they don't support numerous countries east of Iraq which they default to Pacific Standard Time (or GMT+8). This by the way happens to also include Japan (which is GMT-9) and East of Iraq... I'll leave the final conclusion to you... (* GRIN *)
Is this a piece of @!*# or isn't is?