From Internationalization
Revision as of 20:23, 2 October 2013 by Aphillip (Talk | contribs)

Jump to: navigation, search

What Are Floating Times?

Q: What is a "floating time" and how do I handle floating times in my Web application?

A "floating time" or a "floating date" is a time value that isn't tied to a specific time zone.

The Working with Timezones WG Note says:

Some observed time values are not related to a specific moment in incremental time. Instead, they need to be combined with local information to determine a range of acceptable incremental time values. We refer to these sorts of time values as "floating times" because they are not fixed to a specific incremental time value. Floating times are not attached and should never be attached to a particular time zone.

A common example of a floating time value would be a publication date. The January 30, 2013, issue of a newspaper, magazine, or blog posting does not depend on the current local time of the person reading the document. For example, a document might describe its publication date this way:

  <p>Publication Date: <time datetime="2013-01-30">January 30, 2013</time></p>

Problems can arise, however, if Web developers and content authors are not aware of the ways that servers or local JavaScript applications handle date values. For example, the JavaScript Date object is a kind of "incremental" time: it represents the number of milliseconds since an "epoch date". In the case of JavaScript, the epoch data is the same as that used by Unix, the Java programming language, and many other systems: it's defined as midnight, January 1, 1970 in the UTC time zone.

This last bit is important. While a floating time is not tied to a specific time zone, incremental times depend on time zone for their display. So you can easily have code in your Web page that looks like this:

var date = new Date(myPubDateElement.value); var target = document.getElementById("date_target"); target.appendChild(document.createTextNode(date.toDateString()));

Suppose your element "myPubDateElement" contained the value above (2013-01-30). You'd expect the element "date_target" contain a string representing that date. However, if you live in a time zone west of UTC, you'll get a surprise. It says:

Tue Jan 29 2013

The problem here is that many of the Date methods in JavaScript are sensitive to the local system's time zone and they try to present the value using the local time zone's rules. In my case, the time zone is "America/Los_Angeles", which has an offset from UTC of either -8 hours or -7 hours (depending on whether or not daylight savings time is in effect). In the case of this publication date, the "time" portion is zeroed out, so subtracting eight hours from the Date object results in a presentation string that is on the "previous" day. That day might be in the wrong month or even the wrong year.

One way to work around this it to always use UTC (there are methods in JavaScript, for example, that allow one to work strictly in UTC) for floating time values.

Storing and Retrieving Time Data

Another way that floating times are used is in the aggregation of data. For example, suppose you want to track the number of downloads that a user made on a daily basis. If you journal each download, it's easy to reconstruct the list of downloads. Consider:

       "item": "http://www.example.com/downloadMe",
       "date": "2013-10-02T13:17:00Z"

However, this might be cumbersome as the number of downloads grow. You might want to create summary statistics:

       "date": "2013-10-02",
       "numDownloaded": 10

In this particular case, you do want to use local time (non-floating time) to compute the value of "date" when the user starts a download (that is, when you add information to the data). But you'll want to use a consistent (or "floating") frame of reference when retrieving the record.