Time Zone Calculation
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.
Solution 1: Using Cookies (The Adequate Solution)
which is available on our web site at:
and can be called in your HTML code in a manner similar to this:
Make sure that when you call the function
Once this function has been executed, you can then access the cookie
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
allowing the developer of a server-side application to modify his code so it will take this value into account:
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:
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:
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:
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
Please note that each
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:
easier for the server-side application developer:
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.