Subject: [Ietf-calsify] definitive references for UTC

From: sla at ucolick.org (Steve Allen)
Date: Fri Mar 23 21:17:50 2007

I find it somewhat strange that the term "UTC" is used throughout
   draft-ietf-calsify-rfc2445bis-06.txt
without being defined anywhere in the document.

I can't suggest exactly where it would best fit in the rfc,
but a minimal text which defines what UTC is and why it is
used internationally would be something like this:

	Coordinated Universal Time (UTC) is defined by ITU-R TF.460.
	Under the auspices of the Metre Convention of 1865, in 1975
	the CGPM strongly endorsed the use of UTC as the basis for
	civil time.

This implies adding these to the section of Informative References

International Telecommunications Union,
"Standard-frequency and time-signal emissions",
ITU-R TF.460,
http://www.itu.int/rec/R-REC-TF.460/en

General Conference on Weights and Measures,
Resolution 5 of the 15th CGPM,
Comptes Rendus de la 15e CGPM, 1976
http://www1.bipm.org/jsp/en/ViewCGPMResolution.jsp?CGPM=15&RES=5

--
Steve Allen                 <[email-masked]>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99845
University of California    Voice: +1 831 459 3046           Lng -122.06025
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

---

From: lear at cisco.com (Eliot Lear)
Date: Sun Mar 25 09:25:00 2007

<chair hat off>

Steve,

> http://www1.bipm.org/jsp/en/ViewCGPMResolution.jsp?CGPM=15&RES=5

+1.

Thanks for pointing this out.

Eliot

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Mar 26 06:06:52 2007

> 	the CGPM strongly endorsed the use of UTC as the basis for

I'm fine with adding the reference, but it comes with a caveat.

At the Prague meeting, there was consensus that iCalendar should ignore
leapseconds, i.e. act in all respects as if they didn't exist.  I still
think this is both least-surprise for users, and the mode that's almost
certainly implemented by 100% of current iCalendar implementations.

The defining characteristic of UTC, however (as opposed to the other
flavors of Universal Time, or to TAI), is the fact that it has leap
seconds.

Getting this right will require some somewhat tricky wordsmithing in the
document.

-- 
Jonathan Lennox
[email-masked]

---

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Mon Mar 26 06:35:54 2007

> Getting this right will require some somewhat tricky wordsmithing in the

In case anyone doesn't know what I researched recently:
http://www.meinberg.de/english/info/leap-second.htm

"The Windows system clock does not know about leap seconds, either. However, there is a precompiled version of ntpd for Windows available which is capable of slewing the Windows system time quickly in order to account for the insertion of a leap second, without affecting the clock synchronization loop provided by ntpd. "

So in the end I had little choice but to ignore leap seconds as the OS didn't make me aware of them, and without the patch didn't even know about them.

Perhaps an option would be to change the phrasing to describe that support for leap seconds is dependant on support from the clock subsystem and therefore the system may never report their existance.  Then go on to describe how to cope with iCalendar data when your OS doesn't report the leap second.

Equally I'm totally happy with iCalendar ignoring leap seconds too.

Nigel

---

From: mrc at CAC.Washington.EDU (Mark Crispin)
Date: Mon Mar 26 08:32:24 2007

> certainly implemented by 100% of current iCalendar implementations.

That sounds right to me.  For most people, leap seconds are nothing more 
than a form of clock drift correction, and we can (should!) stay out of 
The Great Leap Second Debate.

[Summary of TGLSD: which is more important, keeping time matching the 
earth's rotation, or having a clock which is predictable in the future? 
Personally, I feel that the people who desire the latter would be better 
served by a monotonically incrementing value (a 72 bit nanosecond value 
will last over 500 years!); and those of us who think in terms of yyyy mm 
dd hh mm ss should stay synchronized with the planet since "years", 
"months", and "days" are fundamentally planetary concepts.  But there are 
many reasonable and educated people who feel otherwise.]

> flavors of Universal Time, or to TAI), is the fact that it has leap

Too bad we can't say "just use TAI".  ;-)

> Getting this right will require some somewhat tricky wordsmithing in the

True.  My suggestion is something to the effect that the basic time is 
UTC.  To the extent that any implementation handles leap seconds, they are 
to be treated as a clock drift correction, e.g., 23:59:59 lasts for two 
seconds rather than there being a 23:59:60.

For the purposes of calendaring, an interval lasting for an extra second 
than intended is probably alright, since that is how humans respond to 
leap seconds.  We're not doing precision timekeeping; we're trying to 
synchronize human activities.

I think that we should resist any attempt to make calendaring be a 
precision timekeeping mechanism, since those people have fundamentally 
different needs than calendaring.  Although it's tempting to make one 
protocol shoe fit multiple application feet, the result is rarely 
satsifactory and usually is a wretched compromise that serves nobody.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: wkearney99 at hotmail.com (Bill Kearney)
Date: Mon Mar 26 09:25:02 2007

> Although it's tempting to make one 

+1

---

From: mikesamuel at gmail.com (Mike Samuel)
Date: Tue Mar 27 13:25:55 2007

Most existing date libraries ignore leap seconds, so it's unlikely
that systems built on these will handle them.

I don't think that 2445 uses a <units-since-epoch> representation of
dates, so the only place where UTC enters the picture is in durations
-- subtracting dates, and adding durations to dates.  One alternative
to specifying a different interpretation of UTC, would be to mandate
that PT60S == PT1M.

Here's a quick survey of leap second support in common platforms/libraries:

http://www.mail-archive.com/[email-masked]/msg00109.html
    Distributing leap second tables and requiring hosts to be "on-line"
    to receive them in those days (when UUCP over slow baud modems was
    common) was not considered realistic.  It was felt expect vendors
    and/or system administrators to maintain a complete leap second table
    (including leap seconds announced in advance) was also considered
    unrealistic.

    The POSIX decision was to preserve existing practice.  That the
    vast majority of time-stamp calculation methods ignored leap seconds .
    The decision was to to continue to use a trivial seconds since the
    Epoch" calculation that ignored leap seconds.

http://joda-time.sourceforge.net/faq.html#leapseconds
    Joda-Time does not support leap seconds. Leap seconds can be supported by
    writing a new, specialized chronology, ...

http://docs.python.org/lib/datetime-date.html
    Note that on non-POSIX systems that include leap seconds in their
notion of a
    timestamp, leap seconds are ignored by fromtimestamp().

Similarly java.util.Date only supports leap seconds if the underlying
hardware does.

cheers,
mike

On 26/03/07, Bill Kearney <[email-masked]> wrote:
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>