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:

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

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

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:

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

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:

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

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.

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:

    https://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, 2003	Submitted

This web site was designed, developed, and is maintained by DesiSoft Systems. Visit our web site today to find out how we can enhance your existing site, or you can have us build you a customized web site geared to your particular business needs. Copyright © 2000-2003 DesiSoft Systems. All Rights Reserved. The names of other companies and their products and technologies mentioned herein may be the trademarks of their respective owners.