Of Time and Time Zones--with the Traveler in Mind
Articles and Tips: article
SysOp Engineer, CNE5, ASE
01 Jan 2001
Examines how time zone settings affect the way servers figure Universal Time.
Time and tide wait for no man, or so the saying goes. This is especially true for the poor network administrator whose workstations all of a sudden decide on a strange but common time. "All I did was upgrade the clients," says the administrator, "and now my server time is wrong. What's going on?"
The most likely scenario is that the administrator upgraded from the 2.2 version of the Novell client to a more recent version. In the old days of 2.2, the client would ask the server for the local time. This worked just fine, as long as the client and server were in the same time zone. But nowadays, it is more likely for servers and clients to be in different time zones. Therefore, the newer clients ask the server for the Universal Time Coordinated (UTC) time and then apply whatever time zone offset is set in the workstation's local operating system to get the local time.
The question of time zones becomes especially concerning to the travelling user. When you stay in one place, you need only worry about local time, but travelers need to be mindful of where they are and where they are going. To help illuminate this (ahem) timely issue, let's review what we know about how time is reckoned on planet Earth.
Where It All Began
In navigational aids such as the Nautical Almanac, all times are expressed in Universal Time or UT. For historical reasons, UT was originally called Greenwich Mean Time (or GMT) because that is the local time at the Royal Observatory in Greenwich, England. The decision to use Greenwich as the baseline of global time was made in an era when Britannia ruled the seas. Thus places east of Greenwich are said to be "fast on UT"-- that is, they are ahead in time. Places west of Greenwich are said to be "slow on UT," since they are behind in time when compared to Greenwich. (Of course, it comes as no surprise to the British that America is behind time.)
Figure 1 shows a world map with all the time zones for your reference.
Now comes the confusing part: to derive local time in relation to UT, you can either express the time zone offset as a value you add to your local time or as a value you subtract from your local time to get to UT. On NetWare servers, the former method is used--you add an offset to your local time to get to UT. So if your local time is fast on UT (east of Greenwich), you use the minus sign to reflect the correct UT; conversely, is your local time is slow on UT (west of Greenwich), you use the plus sign to reflect the correct UT.
For example, the local time here in Finland is two hours ahead of UT; hence the time zone setting is EET-2EETD. Western Brazil, on the other hand, is three hours behind UTC and the time zone setting is BRA3BST.
Getting the Time Right
Because of this point of confusion on how to set correct UT, your local time setting can be correct but the UT could be way off if you use the plus sign instead of the minus sign.
As an example, take a computer network in Jakarta, Indonesia. Since Jakarta is east of Greenwich, it can be said to be fast on UT--by seven hours, to be precise. The correct time zone setting should therefore have a "-7" in it. If you inadvertently used the plus sign, the TIME console command on the affected server would produce output similar to the following:
Time zone string: "WIB+7ESUT DST status: OFF DST start: not set Time synchronization is active. Time is synchronized to the network. Monday, October 30, 2000 6:27:20 pm UTC Monday, October 30, 2000 11:27:20 am WIB
Is the server time correct? Well, if the server's local time is 11:27 am, then UT should be seven hours earlier, or 04:27 am. However, the server thinks that UT is 06:27 pm. Since the newer Novell clients ask the server for UT, all the clients will receive incorrect time from the server even though the server's local time is correct.
The solution in this example is simple: get the plus/minus sign correct and change WIB+7ESUT to WIB-7ESUT. Note that this is equivalent to setting the time on the server console, so all the caveats regarding Synthetic Time, drifting time, and other time issues apply to this situation (see TID #10013670 for more details).
Note: When dealing with time measurement, remember to figure in the effects of daylight saving time (DST), which is applied in some time zones to adjust local time ahead or behind, usually by one hour.
For a list of all time zone codes and offsets, see TID #2908587, available at http://support.novell.com .
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.