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

Re: Time Zones in Searches

From: Mark Davis <mark@macchiato.com>
Date: Fri, 26 Oct 2001 09:13:13 -0700
Message-ID: <00a001c15e39$1d64d9e0$0c680b41@c1340594a>
To: "Thierry Sourbier" <webmaster@i18ngurus.com>, "Www-International-w3c-org \(E-mail\)" <www-international@w3.org>
Time measurement, even aside from time zones, can be very tricky. For example, most computer systems do not really use UTC, even when they say they do. What they actually use is Floating TAI.

So what is the difference?

- TAI (International Atomic Time) is essentially just a count of seconds from a given fixed point back in time.

- UTC can be thought of as TAI plus occasional leap seconds inserted, to bring it more into adjustment with the rotation of the earth. Unfortunately, the future leap second additions are only determined a few years in advance, so there is no way to do accurate time measurement with UTC into the future.

- Floating TAI is a mixture of TAI and UTC. The current time on the computer (more or less) is set to UTC, BUTall time calculations are done as if in TAI, and don't take leap seconds into account. So any time measurements into the past or future that go over a leap-second point will not match UTC.

Then, of course, you get into the oddities of the Gregorian Calender, which cause some significant problems. For more information, see http://www.macchiato.com/unicode/timeIntervals.htm


Δός μοι ποῦ στῶ, καὶ κινῶ τὴν γῆν — Ἀρχιμήδης

  ----- Original Message ----- 
  From: Thierry Sourbier 
  To: Www-International-w3c-org (E-mail) 
  Sent: Friday, October 26, 2001 07:19
  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 users).

  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). You'll find may time zone information related links there.


  www.i18ngurus.com - Open Internationalization Resources Directory
    ----- Original Message ----- 
    From: Eric Kreiser 
    To: Www-International-w3c-org (E-mail) 
    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 zone???

    Is anyone doing anything similar?  Any suggestions/comments,etc... are welcome.   
Received on Friday, 26 October 2001 12:12:27 UTC

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