W3C home > Mailing lists > Public > www-international@w3.org > October to December 2001

RE: Time Zones in Searches

From: Eric Kreiser <ekreiser@knowledgeplanet.com>
Date: Fri, 26 Oct 2001 15:30:06 -0400
Message-ID: <79F9FFD2D6FBEC44AF0300030ED530EA46C23E@ksicomm01.knowledgesoft.com>
To: "'Thierry Sourbier'" <webmaster@i18ngurus.com>, "Www-International-w3c-org (E-mail)" <www-international@w3.org>
--Yes, I think I need to convert to UTC.  I have data being entered for time
zones all around the world, some for location based events and others for
virtual event not tied to any specific location.  I need to be able to do
resource checking across all these events to make sure I have all the
resources available in that timeframe.
--I have no way currently to infer a users time zone.  In my case the
ultimate would be if somehow I could get that information from an HTTP
request header in a JAVA servlet.  But, I don't know of any way to do this.
This out asking the user, how else could I know what time zone they are in?
We have discussed storing this information in the database relative to each
--Not sure the accuracy is completely necessary, but I am not sure how to
avoid it from a technical architecture perspective.  How would I totally
ignore time zones during searches without storing every date/time in my
system twice??  The value once converted to UTC, and once in the local
Yes, I am using JAVA 1.3 to do my date/time conversions to UTC, which thru
our testing seems to be accurate.

-----Original Message-----
From: Thierry Sourbier [mailto:webmaster@i18ngurus.com]
Sent: Friday, October 26, 2001 10:19 AM
To: Www-International-w3c-org (E-mail)
Subject: Re: Time Zones in Searches

> Is there a standard/commonly accepted way to search dates with time zones.
A certainly common approach is, as you did, to convert all date/time to UTC
and do the comparaison all comparaison in UTC. Now as you point out this
raises the question of converting to UTC when the user time zone may not be
known. More insights on your application and the use of the dates you are
manipulating would be very usefull to determine if:
- The conversion to UTC is indeed necessary (e.g. if you are storing local
event date and time this may not be necessary).
- There are ways to infer the user time zone (e.g. user login information).
- Your user base can understand the need for time zone (e.g. scientifics).
- Great accuracy is needed (what the system should cover to be useful to the
Also I like to point out that accurate convertion to UTC is not an easy
thing as it is complicated by the fact that many places use daylight saving
making convertion of a time/date in the past or future much more complicated
than having a single offset. Java has greatly enhanced its TimeZone class to
make this sort of calculation much easier, the referring source in the
subject is probably TZ ( http://www.twinsun.com/tz/tz-link.htm
<http://www.twinsun.com/tz/tz-link.htm> ). You'll find may time zone
information related links there.
www.i18ngurus.com <http://www.i18ngurus.com>  - Open Internationalization
Resources Directory

----- Original Message ----- 
From: Eric Kreiser <mailto:ekreiser@knowledgeplanet.com>  
To: Www-International-w3c-org (E-mail) <mailto:www-international@w3.org>  
Sent: Friday, October 26, 2001 3:12 PM
Subject: Time Zones in Searches

Is there a standard/commonly accepted way to search dates with time zones.

I am developing an application that I need to store all dates relative to
time zone.  (Using Oracle 8i as a database)
When the user enters the information, before storing it to the database, I
convert all date/times to UTC (I need a consistent/comparable date/time).
Now the problem, when the user is searching based on these dates
----Is it common to have the user specify a time zone relative to the
date/times on the search screen???
----Or, is it common to have the user just enter a date/time on the search
screen and return items that occurred on that date/time irregardless of time
Is anyone doing anything similar?  Any suggestions/comments,etc... are
Received on Friday, 26 October 2001 15:36:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:40:45 UTC