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
>
>