RE: Draft for review: Working with Time Zones

Hi.


From: addison@lab126.com
To: mark@macchiato.com; duerst@it.aoyama.ac.jp
CC: cowan@mercury.ccil.org; ishida@w3.org; www-international@w3.org
Date: Tue, 15 Feb 2011 22:20:37 -0800
Subject: RE: Draft for review: Working with Time Zones


> Leap Seconds 
> . . .
> * There may be no way to represent a leap second time value using your local incremental units 
> and there 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, . . .
{COMMENT:  I have a personal preference for using a verb, "a minute to have," instead of "of a minute;" also I prefer normally to put the reason for something, the "in order to" clause, first, in order to avoid ambiguity; thus I would say: 
 
=>
 
"For example,
> while Java's java.util.Calendar class, in order to accommodate leap seconds, allows for a minute to have a "61st" second,  . . ."
>
(But these changes are not absolutely essential.)
Best,
--C. E. Whitehead
cewcathar@hotmail.com 
> --
 
> 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> 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