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 form 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.

The range of incremental times that describe 2016-01-30 turns out to span as many as fifty hours. Depending on the time zone used to create and display an incremental time value, the same floating date value could be as much as two days off.

That's because, while a floating time is not tied to a specific time zone, any incremental time values depend on time zone for their display and processing. Since data formats for time values in both server-side (such as Java) and client-side languages (such as JavaScript) are always incremental times, this can lead to issues. For example, 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 (for example, in the America/Los_Angeles time zone), 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 local time zone rules. In the case of a system running in the America/Los_Angeles time zone, which has an offset from UTC of either -8 hours or -7 hours (depending on whether or not daylight savings time is in effect) the value presented to the user from the JavaScript is incorrect because the the "time" portion of the publication date is zeroed out. 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, Retrieving, and Aggregating 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.