RE: Draft for review: Working with Time Zones

Thanks Mark, John, and Martin.

I have updated the document, basing much of my text on your suggestions on this thread (see below). I must admit that I had hoped to avoid covering “off topic” issues such as leap seconds in such depth, but we cover various time keeping issues in such depth that it’s impossible not to cover it at least a bit.

Here is my proposed addition. Comments?

--
Leap Seconds
One quirk of timekeeping is the need for leap seconds. The Earth's rotation is not even and is slowing down. To help address 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 incremental timekeeping systems such as atomic clocks. A leap second 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) do not keep track of leap seconds in their incremental time values. What happens is:

 *   Eventually, the clock is updated externally by the user or via a service such as NTP. Most computer clocks exhibit some amount of clock drift anyway, so this sort of maintenance is not unusual.
 *   No list is kept of past or future leap seconds (and no list exists for dates preceding the advent of leap seconds in 1972), so software often doesn't include leap seconds when calculating the difference between two datetimes. For example, the difference between 12:00:00 Noon on December 31st and 12:00:00 Noon on the following January 1st will always be 86400 seconds, even if a leap second was mandated for the intervening midnight.
 *   There may be no way to represent a leap second time value using your local incremental units and may not be a means of representing a leap second using field-based units. For example, while Java's java.util.Calendar class allows for a "61st" second of a minute to accommodate leap seconds, 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" because the Date doesn't represent leap second values.
If your application cares about or is sensitive to leap seconds, special care must be taken to deal with the loss of leap second precision.
--

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

Internationalization is not a feature.
It is an architecture.

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Behalf Of Mark Davis ?
Sent: Wednesday, February 09, 2011 10:35 AM
To: Martin J. Dürst
Cc: Phillips, Addison; John Cowan; Richard Ishida; www International
Subject: Re: Draft for review: Working with Time Zones

I agree: "ignore" is too simple a term. Also, it should be mentioned that the approach that Java takes is probably the most common way of dealing with them.

Leap-seconds are not ignored, in that the current time takes them into account. But they are ignored in computing past or future time according to the calendar. I've seen the term "floating TAI" to refer to this.

So the epoch time is also not really 1970-01-01T00:00:00; it is really an abstract time which is offset by that by however many leap-seconds have occurred between now and then.

Mark

— Il meglio è l’inimico del bene —

On Tue, Feb 8, 2011 at 20:26, "Martin J. Dürst" <duerst@it.aoyama.ac.jp<mailto:duerst@it.aoyama.ac.jp>> wrote:


On 2011/02/09 2:15, Phillips, Addison wrote:

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.

Personally, I'm not too worried about the year 158421 :-).

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,

Combat sounds a bit too grandiose. We really can't do much to keep up the Earth's rotation, can we? I'd go for 'address'.


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.

I think it would be good if 'ignore' were explained in more detail. I think what it means is all of:
- When a leap second happens, the machine eventually will be told it is late (e.g. via NTP), and will just switch its clock by one second.
- The machine or software doesn't keep a list of leap seconds that have happened in the past.
- The software won't count leap seconds when calculating the difference between two datetimes. E.g. the difference between 12:00:00 noon on Dec. 31 and on the next Jan. 1st will always be 86400 seconds.
- There is no way to internally represent the moment in time of a leap second.
- Conversion from incremental to field-based time can never produce a leap second datetime (that's your example).

Regards,   Martin.

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.





--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp<mailto:duerst@it.aoyama.ac.jp>