RE: Draft for review: Working with Time Zones

> 
> > > It's essential that this be rewritten to take leap seconds into
> > > account, as they say, early and often.
> >
> > Well, once or sometimes twice a year in certain years :-).
> 
> Current provisions allow for a leap second at the end of any month,
> actually, and by the year 158421, we'll have to have a whole hour
> worth of leap seconds every day.
> 

So I changed the specific sentence you quoted to read:

--
For example, the Java type java.util.Date is a long (integer) value. It represents the number of milliseconds since 00:00 (midnight) on January 1, 1970 in UTC (less all of the intervening leap seconds).
--

And then added this subsection:

---
Leap Seconds

One quirk of timekeeping is the need for leap seconds. The Earth's rotation is not even and is slowing down. To combat this problem, the [International Earth Rotation Service] occasionally mandates a "leap second" to keep the calendar and other field-based time values in sync with atomic (incremental) clocks. This usually occurs once or sometimes twice per year and always takes the form of an additional second added to the last minute of the day. Usually the leap second is added to December 31st or June 30th.

As mentioned above, many incremental time values (such as Java's or POSIX's) ignore leap seconds for incremental time values. If your application cares about or is sensitive to leap seconds, it bears noting that conversions from field-based to incremental time (or vice versa) may not take this into account. For example, Java's Calendar class allows for a "61st" second of a minute. If you set a Java Calendar to December 31, 2008 23:59:60 UTC (a recent leap second value) and then convert that to a java.util.Date in order to print it out, you might see: "January 1, 2009 00:00:00 UTC", even though there was a leap second in the Calendar representation of the time. 
--

Does this address your concerns? Do you think there are specific places where we need to mention leap seconds additionally?

Thanks,

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

Received on Tuesday, 8 February 2011 17:15:44 UTC