DesiSoft Systems

Home Page
Services
Products
Clients
White Papers
White Papers
Request Form
Contact Info
Press Releases
Privacy Policy
Site Map
Web Site Credits

Alternative Languages
English
Polski

White Papers
Time Zone Calculation
Do you have a product idea, a contract you would like us to bid on, or comments about our web site?  Click here to tell us!
Submitted: September 9, 2003
Last Updated: September 9, 2003
Synopsis: One of the wonderful things about the Internet is the ability to peruse information across the world at any time of the day or night, regardless of whether the target of your search is awake or asleep. A problem with this approach, however, happens when you’re browsing content that is updated at various intervals throughout the day, and you’d like to know when that content was changed.

The Problem

One of the wonderful things about the Internet is the ability to peruse information across the world at any time of the day or night, regardless of whether the target of your search is awake or asleep. A problem with this approach, however, happens when you’re browsing content that is updated at various intervals throughout the day, and you’d like to know when that content was changed.

When a webmaster is aware that users are browsing her site, she’ll usually make a note on her web site saying what time zone was used to base the times upon or may display the times according to Greenwich Mean Time (GMT). However, this solution is not the best one, since the user browsing her web site then has to add or subtract a number or hours (or minutes in some locations) from the displayed times to come to the time according to their local clock. And, with Summer Time or Daylight Savings Time in effect in different parts of the world, this calculation could be off.

The purpose of this white paper is to propose that web site developers and web browser developers work together to start helping out their users by showing the times their materials were posted on their web sites in the user’s time zone.

Now, if it were so easy, you’d wonder why no one is doing this right now. The answer to that is it hasn’t become so much of an issue with enough users to get the ball rolling. As a matter of fact, there are two possible solutions for this problem, one, which would require the use of cookies (an adequate solution for now), and the other solution, which would require current web browsers’ source code to be modified (the best solution).

Solution 1: Using Cookies (The Adequate Solution)

The best solution is for web browsers to be modified to provide this option. However, until web browser developers change their applications, web site developers can provide a solution by using JavaScript and cookies.

To do this, we wrote a JavaScript function named

    tzCalculation_LocalTimeZone

which is available on our web site at:

    http://www.desisoftsystems.com/tzCalculation_LocalTimeZone.js

and can be called in your HTML code in a manner similar to this:

    

<html>
<head>
<script language="javascript"
    type="text/javascript"
    src=
    "http://www.desisoftsystems.com/tzCalculation_LocalTimeZone.js">
</script>
</head>
<body>
<script language="JavaScript">
<!--
    tzCalculation_LocalTimeZone ('
desisoftsystems.com',false);
-->
</script>
</body>
</html>

Make sure that when you call the function tzCalculation_LocalTimeZone you pass in your domain as the first parameter instead of desisoftsystems.com if you intend to have access to the cookie in your server-side application. For the second parameter, you can pass in false if you don’t want the function to print out the time zone value at the current location in the document. If you pass in true, however, the time zone value will also be printed in your generated document.

Once this function has been executed, you can then access the cookie timezone from your server-side application; its format is the same standard time offset as commonly used in e-mail and other HTTP headers.

Because there’s no 100% portable solution to providing the abbreviated- or long-form time zone strings with JavaScript, those options have not been included in the discussion of this solution. However, an enterprising web site developer could ask her users to add this via a web-based form and then store that in the cookie data for her web site. However, since the most important part of this standard is to show a web site user the times on a web site according to her time zone, these strings are not as important, but should still be stored in the cookie as put forth in Solution 2.

Solution 2: Revising Web Browsers (The Best Solution)

The best solution is for web browsers to start supplying an environment variable to web servers relaying the time zone in which the browser is currently located.

Naturally, many security conscious users will wonder about this solution, but when one considers that it is possible to find out the longitude and latitude of your connection to the Internet based on your IP address (or the IP address of the proxy server your organization uses), such a release of information is rather mild. And, for the security conscious, web browser developers could include in their applications the means to send a different time zone setting than what the user’s computer is using or to not send the setting at all.

As I’m writing this white paper, I just checked on the browser-based environment variables that were supplied to our web server. Here’s a listing of some of them:

Environment Variable Value
HTTP_ACCEPT */*
HTTP_CONNECTION keep-alive
HTTP_HOST polski.local
HTTP_USER_AGENT Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85 (KHTML, like Gecko) Safari/85

When my web browser sent these environment variables to our web server, it sent them in the HTTP header format:

Accept: */*
Connection: keep-alive
Host: polski.local
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85 (KHTML, like Gecko) Safari/85

Now, if a web browser were modified to also include the time zone of the user’s computer in the set of headers it passes to the web server:

Accept: */*
Connection: keep-alive
Host: polski.local
Timezone: -0500 CDT Central%20Daylight%20Time
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85 (KHTML, like Gecko) Safari/85

this set of environment variables becomes available to server-side applications:

Environment Variable Value
HTTP_ACCEPT */*
HTTP_CONNECTION keep-alive
HTTP_HOST polski.local
HTTP_TIMEZONE -0500 CDT Central%20Daylight%20Time
HTTP_USER_AGENT Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85 (KHTML, like Gecko) Safari/85

For example, in Perl, this environment variable could be referenced as

    $ENV{'HTTP_TIMEZONE'}

allowing the developer of a server-side application to modify his code so it will take this value into account:

    -0500 CDT Central%20Daylight%20Time

when calculating times and dates to be displayed on the generated web page.

The values that a web browser should send to the web server are defined in the following order:

  • A standard time offset as commonly used in e-mail and other HTTP headers
  • A space character (0x20, decimal 32, ' ', U+0020)
  • The time zone in abbreviated form
  • A space character
  • The time zone in long form

The time zone in abbreviated and long form should be sent in UTF-8 format and URL-encoded (in the example, you will notice that the spaces in the long-form time zone are represented with %20), but are progressively optional, meaning that the offset is required, but the time zone strings are not. However, if you include a long-form time zone string, you must include the abbreviated-form time zone string, but you don’t need to include a long-form time zone string if you include an abbreviated-form time zone string. Syntactically, you could write this set of requirements in the following manner with brackets [] denoting the optional elements:

    Timezone: offset [abbrev-time-zone-string [long-time-zone-string]]

A web browser designed to provide special cases for its security-conscious users could include a set of preferences that would turn off the sending of the abbreviated- and long-form time zone strings but still send the offset, allowing accurate time display but not giving away a specific geographical location (regardless of how large that area may be—after all, the entire Earth is divided into at least 24 time zones, not counting those that exist on non-hour boundaries).

In the example, this would signify an offset of five hours prior to GMT, since Dallas, TX, is observing Daylight Savings Time at the time I’m writing this white paper. If it were written a little over a month later, when Daylight Savings Time ends, the value sent would be:

    -0600 CST Central%20Standard%20Time

The reason for encoding the time zone strings in UTF-8 is because Unicode is now a widely adopted standard that encodes practically all useful character data (it’s not exhaustive, but it’s growing and, for all practical purposes, is complete), and for non-Latin-based languages, these strings may not be representable in the ASCII or ISO-8859-1 character sets, as can be seen from the following table.

Example
City
Normal
Name
Normal
Abbreviation
Normal
Time
Example
Normal
Offset
from GMT
Summer/
DST
Name
Summer/
DST
Abbreviation
Summer/
DST
Time
Example
Summer/
DST
Offset
from GMT
Dallas Central
Standard
Time
CST Sunday
12:00 pm
-0600 Central
Daylight
Time
CDT Sunday
1:00 pm
-0500
Greenwich Greenwich
Mean
Time
GMT Sunday
6:00 pm
+0000 N/A
Tokyo 日本標準時 JST Monday
3:00 am
+0900 N/A
Kabul,
Afghanistan
وقت افغانستان AFT Sunday
10:30 pm
+0430 N/A
Seoul 한국표준시 KST Monday
3:00 am
+0900 N/A
Berlin Mitteleuropäische
Zeit
MEZ Sunday
7:00 pm
+0100 Mitteleuropäische
Sommerzeit
MESZ Sunday
8:00 pm
+0200

The above table is also available as a graphic if you don’t have the necessary fonts on your system.

As you can see, although both Japan and South Korea lie within the same time zone, they both name the time zone differently. Also, of great importance, is the fact that Kabul, Afghanistan, lies in a time zone that is 4 hours and 30 minutes ahead of GMT, which is not an hour-divisible value, so server-side application developers should always check the entire value passed to them and not just the hour component.

Using the time zones displayed in the above table, the Timezone header passed from a web browser to a web server would be as follows:

  • Dallas (CST and CDT)
    Timezone: -0600 CST Central%20Standard%20Time
    Timezone: -0500 CDT Central%20Daylight%20Time

  • Greenwich (GMT)
    Timezone: +0000 GMT Greenwich%20Mean%20Time

  • Tokyo (JST)
    Timezone: +0900 JST %E6%97%A5%E6%9C%AC%E6%A8%99%E6%BA%96
              %E6%99%82

  • Kabul, Afghanistan (AFT)
    Timezone: +0430 AFT %D9%88%D9%82%D8%AA%20%D8%A7%D9%81%D8
              %BA%D8%A7%D9%86%D8%B3%D8%AA%D8%A7%D9%86

  • Seoul (KST)
    Timezone: +0900 KST %ED%95%9C%EA%B5%AD%ED%91%9C%EC%A4%80
              %EC%8B%9C

  • Berlin (MEZ and MESZ)
    Timezone: +0100 MEZ Mitteleurop%C3%A4ische%20Zeit
    Timezone: +0200 MESZ Mitteleurop%C3%A4ische%20Sommerzeit

Please note that each Timezone string should be sent on one line, regardless of any formatting differences displayed in this document.

There are, of course, far more examples we could cite, but these are representative of the issues that a web browser or web server developer should consider when implementing this standard. The data used in these examples was taken from the web sites for Greenwich Mean Time and IBM’s International Components for Unicode.

Most operating systems already provide these strings as part of their core set of APIs. If they don’t, the web browser is responsible for retrieving these settings from the user through a preference setting.

Of course, it may be possible that some web servers and server-side development environments may need to be revised for this solution to work, but if they have been following the standards put forth by the World Wide Web Consortium (W3C), this shouldn’t be a concern for web site developers (the web server we tested this against was Apache/1.3.27, the version supplied with Mac OS X 10.2.6).

An obvious set of environment variables that could be created by web servers and server-side development environments would be the following, making the interpretation of this data:

    Timezone: -0500 CDT Central%20Daylight%20Time

easier for the server-side application developer:

    HTTP_TIMEZONE_OFFSET:  -0500
    HTTP_TIMEZONE_OFFSET_MINUTES:  -300
    HTTP_TIMEZONE_ABBREV:  CDT
    HTTP_TIMEZONE_ABBREV_ENCODED:  CDT
    HTTP_TIMEZONE_LONG:  Central Daylight Time
    HTTP_TIMEZONE_LONG_ENCODED:  Central%20Daylight%20Time

Conclusion

In the interest of promoting open standards, you are free to use the source code in this white paper and the code available in this JavaScript source file:

    http://www.desisoftsystems.com/tzCalculation_LocalTimeZone.js

to implement this solution to this world-wide problem.

DesiSoft Systems makes no warranty as to the correctness of any supplied software nor is liable for any loss whatsover from any use thereof. Should you have any suggestions or need to report any bugs you discover while using this software, we would appreciate hearing from you.


Please let us know your comments about this white paper on our White Paper Comments Form.


Changes
September 9, 2003Submitted