Re: Draft for review: Working with Time Zones

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

Received on Wednesday, 9 February 2011 04:27:30 UTC