Difference between revisions of "FloatingTime"

From Internationalization
Jump to: navigation, search
(Q: What is a "floating time" and how do I handle floating times in my Web application?)
m (What Are Floating Times?)
Line 36: Line 36:
  
 
One way to work around this it to always use UTC (and there are methods in JavaScript, for example, that allow one to work strictly in UTC) for floating time values.
 
One way to work around this it to always use UTC (and there are methods in JavaScript, for example, that allow one to work strictly in UTC) for floating time values.
 
== In detail ==
 

Revision as of 16:50, 5 March 2013

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. That is, 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, my 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 for the date given). In the case of my 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 (and there are methods in JavaScript, for example, that allow one to work strictly in UTC) for floating time values.