Subject: ITC copped out on UTC again

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jan 2012 09:20:50 -0500

If we are ever going to get a handle on Internet time we need to get rid of
the arbitrary correction factors introduced by leap seconds.

The problems caused by leap seconds are that they make it impossible for
two machines to know if they are referring to the same point in future time
and quite often introduce errors in the present.

1) No machine can determine the number of seconds between two arbitrary UTC
dates in the future since there may be a leap second announced.

2) If Machine A is attempting to synchronize with machine B on a future
point in time, they cannot do so unless they know that they have the same
view of leap seconds. If a leap second is announced and only one makes the
correction, an error is introduced.

3) In practice computer systems rarely apply leap seconds at the correct
time in any case. There is thus a jitter introduced around the introduction
of leap seconds as different machines get an NTP fix at different points in
time.

4) Even though it is possible to represent leap seconds correctly in
standard formats, doing so is almost certain to exercise code paths that
should be avoided.

Since the ITU does not look like sorting this out, I suggest we do so in
the IETF. There is no functional reason that Internet protocols should need
leap seconds.

I suggest that the IETF plan to move to Internet Time in 2015, immediately
after the next ITU meeting. Internet time would be TAI plus the number of
leap seconds that have accumulated up to the next ITU decision point. So if
UTC drops leap seconds at the next meeting the two series will be in sync,
otherwise there will be a divergence.

-- 
Website: http://hallambaker.com/

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 20 Jan 2012 14:41:24 +0000

Phillip,

> the arbitrary correction factors introduced by leap seconds.

Your arguments in favour of abolishing leap seconds are all good.  But can
you please do us all a favour and provide a similarly lucid list of reasons
that an apologist would use to say that leap seconds should be kept.

Nick

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Jan 2012 15:41:52 +0100

Hi Phillip,

For those who are interested in the proceedings, they took place
yesterday at the ITU's Radio Advisory Group (RAG).  The United States
introduced the proposal to do away with leap seconds.  They were not,
shall we say, universally supported.  Those in favor were largely in
line with what you wrote below, Phillip.  Those opposed were not clear
that there really was a problem to solve, and wanted more time to
consult.  The matter was referred back to the study group for further
consideration, as well as broader consultation, and will be taken up
again at the next RAG (approximately two years from now). 

If you have a TIES account at the ITU, you can listen to the proceedings
by going to the following link and moving to time index 1:43:15 or so.

http://www.itu.int/ibs/ITU-R/RA12/links/1-20120119-1400-en.smil

Regards,

Eliot

On 1/20/12 3:20 PM, Phillip Hallam-Baker wrote:
> If we are ever going to get a handle on Internet time we need to get
> rid of the arbitrary correction factors introduced by leap seconds.
>
> The problems caused by leap seconds are that they make it impossible
> for two machines to know if they are referring to the same point in
> future time and quite often introduce errors in the present.
>
> 1) No machine can determine the number of seconds between two
> arbitrary UTC dates in the future since there may be a leap second
> announced.
>
> 2) If Machine A is attempting to synchronize with machine B on a
> future point in time, they cannot do so unless they know that they
> have the same view of leap seconds. If a leap second is announced and
> only one makes the correction, an error is introduced.
>
> 3) In practice computer systems rarely apply leap seconds at the
> correct time in any case. There is thus a jitter introduced around the
> introduction of leap seconds as different machines get an NTP fix at
> different points in time.
>
> standard formats, doing so is almost certain to exercise code paths
> that should be avoided.
>
>
> Since the ITU does not look like sorting this out, I suggest we do so
> in the IETF. There is no functional reason that Internet protocols
> should need leap seconds. 
>
> I suggest that the IETF plan to move to Internet Time in 2015,
> immediately after the next ITU meeting. Internet time would be TAI
> plus the number of leap seconds that have accumulated up to the next
> ITU decision point. So if UTC drops leap seconds at the next meeting
> the two series will be in sync, otherwise there will be a divergence.
>
>
>
> -- 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Tim Bray <[email-masked]>
Date: Fri, 20 Jan 2012 07:13:43 -0800

One consequence of your proposal, if adopted, is that there will need
to be a specification of the canonical Internet-time-to-Sidereal-time
function, so that in the long run, the time that your computer says it
is will correspond with what you observe looking out the window. The
Internet will be around long enough that this will indeed become a
problem.

I'd want to look at that specification before getting passionate pro
or contra in this argument. -T

On Fri, Jan 20, 2012 at 6:20 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> The problems caused by leap seconds are that they make it impossible for two
> machines to know if they are referring to the same point in future time and
> quite often introduce errors in the present.
>
> Since the ITU does not look like sorting this out, I suggest we do so in the
> IETF. There is no functional reason that Internet protocols should need leap
> seconds.
>

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Jan 2012 15:13:47 +0000

> that an apologist would use to say that leap seconds should be kept.

I agree that leap seconds are a horrible bodge that would be best got rid
of. The reasons to keep them mainly revolve around systems that require
UT1, i.e. the angle of rotation of the Earth, and the protocols that
disseminate UT1.

These include:
Astronomical systems
Space and satellite ground stations
Time broadcast standards

Many protocols and software implementations rely on the guarantee that
DUT1 (the difference between UTC and UT1) is less than 0.9s. For instance
many time broadcast formats don't have space for larger values of DUT1.

Many instruments that point at the sky rely on the fact that DUT1 <
0.9s for establishing an initial rough aim.

For more examples see http://futureofutc.org/preprints

At a more philosophical level a lot of people find it difficult to accept
the idea of decoupling time from Earth rotation, to the extent that they
say it is obvious nonsense or foolishness, even though the rate error is
only one second every year or two. However UT1 is slowing down
quadratically, so the time scales will diverge increasingly rapidly.

We can paper over this difference by adjusting time zones every few
hundred years. In fact time zone adjustments will work further into the
future than leap seconds. But speculating about what will happen that far
into the future is foolish.

Numbers for divergence between UTC and TAI:
http://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole, Lundy, Fastnet, Irish Sea, Shannon: West 5 to 7, occasionally gale 8
later in Irish Sea. Moderate or rough, occasionally very rough except in Lundy
and Irish Sea. Occasional rain or drizzle. Good, occasionally poor.

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 20 Jan 2012 10:14:28 -0500

The solution is simple - move to TAI. That is the _true_ time, what
the master clocks actually keep. UTC is just a variant for creatures
living on the surface of the Earth.

> dates in the future since there may be a leap second announced.

Not true for TAI.

> correction, an error is introduced.

Not true for TAI

> of leap seconds as different machines get an NTP fix at different points in

Not an issue for TAI

> standard formats, doing so is almost certain to exercise code paths that

Not an issue for TAI

Note, also, that the ITU proposal is not to _remove_ leap seconds, but
to stop _issuing_ them (i.e., it could be rescinded fairly easily if
in say 20 years someone agitated strongly to bring leap seconds back).

> otherwise there will be a divergence.

Makes no sense to me. Please don't continue to create more time scales
that are "TAI plus some arbitrary constant."

I believe that would make at least 4  separate ones (ET/TDT/TT, UTC,
GPS internal time, plus this), which would be IMO at least 4 too many.

If there is to be an internet time, it should simply be TAI. Then, the
conversion to UTC is just an addition, and there would be no reason to
have the messy interpolation during a leap second. just to change the addend.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 20 Jan 2012 10:18:59 -0500

> or contra in this argument. -T

The people who really care about this (i.e., astronomers) already use
TAI to do it.

I have written such code (more than once), the first thing you do is
to find UT1 - TAI, then proceed with various rotations from
there.

50 years ago, using UTC as an approximation to UT1 when you didn't
happen to have a multi-million dollar, multi-ton, mainframe in your
pocket made sense. Today, when that same power (or, actually, more) is
in your smart phone (if not your toaster), it doesn't.

Regards
Marshall

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 20 Jan 2012 15:27:37 +0000

> into the future is foolish.

it's also a valid concern.  Abolishing leap seconds kicks the can down the
road as far as this is concerned.  And while it's tempting to push this
sort of decision down on future generations, they're not going to love us
for it in a couple of hundred years if they need to adjust by an hour to
get solar time in sync with UTC again.  Of course, you can talk about this
and say that it's a theoretical nicety, but it will also break the tie
between TAI and UTC at that stage, which invalidates most of Phillip's
arguments to some degree or other - not to a degree that affects us here
and now, but that will affect humankind in the future.  That's assuming
that we haven't reverted to hunting with spears by that stage.

I'm not arguing the point either way, btw.  Just pointing out that there's
a lot more to this argument than Phillip's clear and well-articulated
reasons why leap seconds should be abolished.

Nick

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 20 Jan 2012 10:32:07 -0500

> Space and satellite ground stations

All of these are computer controlled now-a-days, and have been for
some time. Even in the 1980's, the computer systems used
UT1, not UTC.

> 0.9s for establishing an initial rough aim.

Not so much the professional ones.

> For more examples see http://futureofutc.org/preprints

Look at Daniel Gambis' survey

Preprint-668

(~ 75% in favor of not changing anything).

> quadratically, so the time scales will diverge increasingly rapidly.

Yes. Note that for the same reason leap seconds will, in a century or so, start
to come very frequently.

> http://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable

My actual proposal, if I were to make one, would be to keep UTC, but
to make TAI "Internet time" and try and
move most electronic things to TAI, keeping UTC only for civil time.

Note that time is tricky and slippery and _any_ change, even this one,
will have some painful consequences, for somebody, and  past
experience is that some of those won't be found until the change is made.

Regards
Marshall

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Jan 2012 15:49:01 +0000

Nick Hilliard <[email-masked]> wrote:
>
> Abolishing leap seconds kicks the can down the road as far as this is
> concerned.  And while it's tempting to push this sort of decision down
> on future generations, they're not going to love us for it in a couple
> of hundred years if they need to adjust by an hour to get solar time in
> sync with UTC again.

Yes.

> Of course, you can talk about this and say that it's a theoretical
> nicety, but it will also break the tie between TAI and UTC at that
> stage, which invalidates most of Phillip's arguments to some degree or
> other - not to a degree that affects us here and now, but that will
> affect humankind in the future.

No, a timezone change (or rather a series of timezone changes) doesn't
affect the relationship between UTC and TAI. The changes don't even need
global co-ordination.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Jan 2012 15:52:26 +0000

Marshall Eubanks <[email-masked]> wrote:
>
> My actual proposal, if I were to make one, would be to keep UTC, but to
> make TAI "Internet time" and try and move most electronic things to TAI,
> keeping UTC only for civil time.

This doesn't actually fix the problems that Phill listed, and it conflicts
with standards such as POSIX.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Faeroes, South-east Iceland: Southwesterly 5 or 6, becoming cyclonic 7 to
severe gale 9, occasionally storm 10. Very rough or high, occasionally very
high in Faeroes. Rain or squally showers. Good, occasionally poor.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 20 Jan 2012 15:56:27 +0000

> affect the relationship between UTC and TAI. The changes don't even need

you could deal with this using TZ changes, but that's turning it into
someone else's problem.  Not so much kicking the can down the road as
pushing the problem up the political stack (not particularly wanting to mix
metaphors).  And fixing the problem at a political level requires some sort
of semi-coordinated global legislation.

Nick

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Jan 2012 15:59:12 +0000

> of semi-coordinated global legislation.

Yes, that's exactly what the ITU-R is doing here. Remember it is a UN
treaty organization.

Tony.

---

From: Ofer Inbar <[email-masked]>
Date: Fri, 20 Jan 2012 13:04:41 -0500

If the main problem with leap seconds is their future
unpredictability, isn't there a compromise option between the status
quo and no more leap seconds?  Couldn't they come up with a fixed
schedule for leap seconds for many centuries at a time, based on
current predictions of approximately how many will be needed each
century?

That should be good enough to prevent real human-noticeable drift
between UTC and perceived day/night time.  If a correction is needed
because current predictions turn out to be wrong, it seems that could
be done very rarely, with centuries of lead time in changes to the
schedule.  Was anything like this considered at the international level?

[ I know this is not something the IETF can decide, of course ]
  -- Cos

---

From: Michael Richardson <[email-masked]>
Date: Fri, 20 Jan 2012 13:13:58 -0500

>>>>> "Phillip" == Phillip Hallam-Baker <[email-masked]> writes:
    Phillip> If we are ever going to get a handle on Internet time we
    Phillip> need to get rid of the arbitrary correction factors
    Phillip> introduced by leap seconds.

    Phillip> The problems caused by leap seconds are that they make it
    Phillip> impossible for two machines to know if they are referring
    Phillip> to the same point in future time and quite often introduce
    Phillip> errors in the present.

Can you tell me which protocols use future timestamps in an moving form
(not stored at rest in a certificate in a DANE RR, for instance), which
care about discrepancies of less than 1 minute?

I'm asking for information.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 20 Jan 2012 13:16:05 -0500

> [ I know this is not something the IETF can decide, of course ]

So, many of these discussions and suggestions seem to be at best addressing a symptom (time is diverging) versus the actual issue (the planet is slowing down) -- this feels to me like a bandaid over a gaping wound.

So, my proposal is that, at the next meeting, we all face counter to the rotation and blow really hard -- Lord knows that we generate enough hot air, maybe we can finally put some of it to good use.

I'm considering proposing a bar BOF so that we can determine just how long we would need to blow for. Obviously different folk generate vastly different amounts of hot air, and so factors like this would need to be taken into consideration, etc.

W

---

From: todd glassey <[email-masked]>
Date: Fri, 20 Jan 2012 10:25:00 -0800

>     Phillip> errors in the present.

BULL. Sorry Phillip - but this is ONLY about the need to create
something that is stronger than the word of the systems administrator.
The issue is that NTP is broken. Both in its design and its use
processes  today.

The architecture of the time-sychronization process was specifically
designed to not produce evidence. What is produces is uncorrelated time
data.

> I'm asking for information.

Power use tokens, any number of FIX type events which create timestamps
representing financial information. Any number of others too.

-- 
Todd S. Glassey
This is from my personal email account and any materials from this
account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

---

From: Clint Chaplin <[email-masked]>
Date: Fri, 20 Jan 2012 11:15:17 -0800

The earth's rate of rotation is not uniform, and the rate of change of
that rotation is not uniform, either.  For instance, I believe, one of
the major earthquakes recently caused a change in the earth's rotation
because of conservation of angular momentum.  ice cap melting may
cause similar changes.

So, predicting future rates and rate of change is not possible.

-- 
Clint (JOATMON) Chaplin
Principal Engineer
Corporate Standardization (US)
SISA

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 20 Jan 2012 11:19:44 -0800

Hi -

> From: "Michael Richardson" <[email-masked]>
> To: "Phillip Hallam-Baker" <[email-masked]>
> Cc: "IETF Discussion Mailing List" <[email-masked]>
> Sent: Friday, January 20, 2012 10:13 AM
> Subject: Re: ITC copped out on UTC again
...
> care about discrepancies of less than 1 minute?

The disman Scheduling MIB (RFC 3231) has future timestamps. They
are defined as dates / times, with provision for how discontinuities
in civil time (whether due to "summer time", time zone changes, or leap
seconds) are to be handled.  This definition makes it unlikely that
a sane developer would internally represent them as computed
intervals.  Leap second handling is a big non-issue in SNMP-land,
as far as I know.

Randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Jan 2012 08:26:44 +1300

> the arbitrary correction factors introduced by leap seconds.

Time is and always will be an arbitrary measurement scheme, and the only
thing that makes sense for the Internet is to use the same arbitrary scheme
as everybody else. We just have to suck up the resulting inconveniences,
as GPS has to. It would be unthinkable to go it alone.

Alternatively we could revert to the Julian (365.25 day) calendar, which
was considerably more convenient for programmers, or perhaps to one of the
old Iranian (360 day) calendars, which are convenient in some ways but do
require occasional leap months.

   Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jan 2012 14:51:08 -0500

If I was designing a protocol from scratch that required accurate time, I
would indeed use TAI. In fact I am planning to do exactly that.

The problem here is fear of the unknown. A small clique that has a very
narrow set of interests (and not ones I find very important) has by
tradition and inertia been left to decide this issue according to what
suits them. Proposing to introduce a third scheme and even more confusion
is a bad technical strategy but possibly an effective political strategy.
It is like threatening civil disobedience, once someone decides that they
care enough to risk breaking the system it becomes much harder to defend
the status quo.

I agree with Brian's points about the fact that time is an arbitrary
quantity. One relativity is considered, time becomes a mindbendlingly
complex notion. The poles are moving at a different speed relative to the
equator for a start. And the orbit of the earth is chaotic. Oh the fun
people can have if they want to try to issue correction factors.

Add to that the fact that the prime meridian is located on a tectonic plate
that is essentially floating on a sea of molten magma.

Let time be time and let people who want to tie physical phenomena to time
work out the relevant correction factors.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 20 Jan 2012 15:20:42 -0800

Brian,

> as GPS has to. It would be unthinkable to go it alone.

+1

> require occasional leap months.

Or a lunar calendar.  Some years, it would be nice to have an extra month :-)

Bob

---

From: Pete Resnick <[email-masked]>
Date: Fri, 20 Jan 2012 19:44:43 -0600

On 1/20/12 5:20 PM, Bob Hinden wrote:
> Or a lunar calendar.  Some years, it would be nice to have an extra month:-)
>    

I hear there are some nice folks at Johns Hopkins with a plan. :-)

http://henry.pha.jhu.edu/calendar.html

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Eliot Lear <[email-masked]>
Date: Sun, 22 Jan 2012 17:17:41 +0100

On 1/20/12 7:13 PM, Michael Richardson wrote:
> Can you tell me which protocols use future timestamps in an moving
> form (not stored at rest in a certificate in a DANE RR, for instance),
> which care about discrepancies of less than 1 minute? 

iCal, for one, which can be used for recurring events that have nothing
to do with computers.  Also relevant, would be the POSIX 1003.1 TZ
offset variable that takes into account seconds.  I mention it because
it can be used to correct for seconds, should the need ever arise.

Eliot

---

From: todd glassey <[email-masked]>
Date: Sun, 22 Jan 2012 09:56:45 -0800

On 1/20/2012 7:13 AM, Tim Bray wrote:

> function, 

No actually there isn't such a need Tim. Its one of the problems we face
here in the timekeeping world.

In fact let me respond as a professional timekeeper since it appears as
I am the only one here.

> so that in the long run, the time that your computer says it
> is will correspond with what you observe looking out the window. 

OK - I disagree. Global time should not be local time. If people are too
stupid to deal with that wait another 30 yeas and those idiots will all
be gone... as in dead - and the new crop of talent will have grown up
with the fact that time is mutable.

The issue of the Internet being around you cite below also pertains to
space based commerce, so in designing a system that only works on this
planet you repeat the previous mistake.

The
> Internet will be around long enough that this will indeed become a

So again the issue here is that protocols and software today are
implemented to need this support. That is the way were designed, i.e. in
a manner which specifically causes this thing now being identified as a
problem.

>> the arbitrary correction factors introduced by leap seconds.

OK I can see this. Why cannot the Internet track TAI and a TAI to
real-world offset table be kept and published by NIST, NPL, PTB, NRC,
NITC or how about from NTP.ORG for instance... its their protocol right?

Seems simple to make the client-side of the NTP implementation totally
responsible for the time conversion if its even necessary. That's a
reference port change and not a protocol change per se as well meaning
it doesnt take the IETF to approve that at all.

>> quite often introduce errors in the present.

No... they just require something more than the limited use time
synchronization tools around today like NTP for instance.

>> correction, an error is introduced.

Yes but is a failing of NTP... not leap seconds.

>> time in any case. 

What you mean is that the time-keepers rarely apply the leap second
properly. Time in the production world comes from automated sources in
most instance so this is a non-issue.

>> There is thus a jitter introduced around the introduction

Oh that's funny. Jitter introduced into a system which is not attesting
to anything, or otherwise tied to most global commerce. What could this
'jitter' actually do?

>> IETF. There is no functional reason that Internet protocols should need leap

I suggest that this may cause a rift between the IETF and other Global
Standards Orgs and that its something that shouldn't happen here.

I also suggest that this is outside the IETF's charter or scope of
operations and that it can be fixed inside the NTP working group as a
design issue before being submitted to the IETF for cannonization.

>> after the next ITU meeting.

I suggest that Internet Time should be pure TAI and simply be a
standardized counter of offset (TAI offset) from the EPOCH and that
anyone supplying time to the world will need a method of specifying
whether its adjusted for Earth Offsets and Time of Day or whether its
pure TAI.

 Internet time would be TAI plus the number of
>> leap seconds that have accumulated up to the next ITU decision point.

NO - Again - the Internet Time should be pure TAI. Securities Trading
Time should be pure TAI. Financial Transaction Time should be pure TAI.

 So if
>> otherwise there will be a divergence.

It is OK for them to be different values.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 22 Jan 2012 21:27:02 -0500

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:
    >> Can you tell me which protocols use future timestamps in an
    >> moving form (not stored at rest in a certificate in a DANE RR,
    >> for instance), which care about discrepancies of less than 1
    >> minute?

    Eliot> iCal, for one, which can be used for recurring events that
    Eliot> have nothing to do with computers.  Also relevant, would be

Forgive me for being dense, but I don't understand how this is relevant.

iCal, as far as I can understand, stores start/end dates in human form.
For instance, from RF2445:
     BEGIN:VTIMEZONE
     TZID:US-Eastern
     LAST-MODIFIED:19870101T000000Z
     BEGIN:STANDARD
     DTSTART:19971026T020000
     RDATE:19971026T020000
     TZOFFSETFROM:-0400
     TZOFFSETTO:-0500
     TZNAME:EST
     END:STANDARD
     BEGIN:DAYLIGHT
     DTSTART:19971026T020000

I don't see seconds-since-epoch anywhere here, I see years since
guy-was-nailed-to-cross here.  As such, that number is assumed to
already be adjusted for leap-seconds, so it's a non-issue.

What I'm looking for is a protocol where a hostA says to hostB,
  "lets meet behind the red-router for a 4.2s tryst 27.563456years from
   now"  

it's important that the period of time until the meeting be large, and
the precision of the meeting be small enough so that the uncertainty due
to leap-seconds exceed the precision of the meeting time.

We do not know how many/when leap seconds will be inserted in the next
hundred years, but based upon one every 2-3 years, it would be around
one hundred years before the accumulated uncertainty due to whether it
was one every 2 years or one every 3 years, begins to exceed 1 minute.

I've heard statements about financial systems, and I've obtained the FIX
specifications from http://fixprotocol.org. (The copyright permits
redistribution, but fixprotocol.org makes you register to get the .zip
file... )  and as far as I can see in my naivety, few timestamps in this
protocol are likely to exceed 1 year, and none of them would seem to
need a precision of less than 1 minute.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 23 Jan 2012 10:52:23 +0100

> living on the surface of the Earth.

Being one of those creatures, I voted for keeping leap seconds.  UTC
seems to fit the global Internet quite nicely, although it has some
problems.  When we'll inhabit faraway planets and use some other time
reference, we'll be facing /more/ problems, not less.

>> dates in the future since there may be a leap second announced.

TAI is computed after averaging several clocks, so it is not known in
advance either.  Both UTC and TAI are labels, albeit the latter is
smoother.

>> correction, an error is introduced.

The problem is still ill-defined for faraway or accelerated machines,
according to relativity.  For practical purposes, the divergence of
their timekeeping is likely, unless they are well connected to a
common time reference.  In that case, they can as well connect to one
another, no?

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Jan 2012 11:05:50 +0100

> Forgive me for being dense, but I don't understand how this is relevant.

You're right, but you asked the wrong, though.  To begin with, protocols
don't care about anything.  It's the people running the applications and
services using the protocols that care.  We can't say how iCal is being
used everywhere.  It is entirely possible that someone is using the
format for something akin to cron(8).

>      LAST-MODIFIED:19870101T000000Z
               YYYYMMDD HHMMSS

Note the "SS" at the end.

I'll also note that the TZ database handles leap seconds but can also be
used to adjust against UTC in some way.  Note I'm not suggesting this,
and I'm really glad we have a few years to think about it.  Good time to
have the dialog, however...

Eliot

---

From: Tony Finch <[email-masked]>
Date: Mon, 23 Jan 2012 12:14:55 +0000

> that rotation is not uniform, either.
>

Even so, the current state of the art is that leap seconds could be
scheduled three years in advance and keep within the |DUT1| < 0.9s limit.
That would make it easier to cope with leap seconds tables as part of
routine software updates, whereas with the current 6 month warning many
systems need to treat the data as dynamic, and this in turn causes
bootstrap problems.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle, Faeroes: Northwesterly 5 to 7, occasionally gale 8 for a time in
north Faeroes, becoming variable 4, then southeasterly 4 or 5 in south later.
Rough or very rough. Wintry showers. Good, occasionally poor.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 23 Jan 2012 12:34:06 +0000

Just curious, but I've often used the formulation:

    day = (now - now % 86400)

where "now" is the output of "gmtime()" of equivalent to calculate the number of days since the epoch.

How is this affected (or not) by the presence of leap seconds, and/or any proposal to remove them.

Ray

---

From: Tony Finch <[email-masked]>
Date: Mon, 23 Jan 2012 13:26:26 +0000

Brian E Carpenter <[email-masked]> wrote:
> thing that makes sense for the Internet is to use the same arbitrary
> scheme as everybody else. We just have to suck up the resulting
> inconveniences, as GPS has to. It would be unthinkable to go it alone.

Most of the above is correct, but the difficulty with UTC is not
arbitrary.

There are two important ways of measuring time: either as a precisely
uniform series of SI seconds (which has been possible only since the
invention of atomic clocks) or as the angle of the earth relative to the
sun (the traditional way). The Earth is not a uniform or stable oscillator
so we cannot easily predict the exact relation between atomic time and
earth time.

UTC is a bodge that tries to accommodate these conflicting forms of time
in one timescale.

Yes, the length of the second and our notations for time and date are
arbitrary, but it is not possible to replace them with a new rational
arrangement that would make something like UTC less vexing, because there
is no standard unit of time that evenly divides the unpredictably variable
length of the day.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Utsire, South Utsire: Southerly or southeasterly 5 to 7, decreasing 4 at
times. Moderate or rough. Wintry showers. Good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Mon, 23 Jan 2012 13:32:01 +0000

> any proposal to remove them.

It is not affected because it is guaranteed to work by POSIX's definition
of "seconds since the epoch", which ignores leap seconds.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon, South Rockall: Variable 4, becoming cyclonic, then southwesterly, 5
to 7, perhaps gale 8 later in south Rockall. Rough. Occasional rain. Moderate
or good.

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 23 Jan 2012 13:03:35 -0500

> advance either.  Both UTC and TAI are labels, albeit the latter is

That is a dodge. While no time system is known perfectly in real time,
there are a number of clocks slaved to TAI that can be used to realize
TIA in real time to much better than microsecond accuracy (and, of
course, that is how we get real time UTC).  In any case, the use case
being mentioned is about the difference between arbitrary, but
specified, epochs, which is independent of the actual errors in the
time system being used.

> common time reference.  In that case, they can as well connect to one

It's not ill defined at all, as long as GR and SR are correct. Both
make very precise predictions about the difference between
measurements made between clocks keeping proper time (i.e., freely
running clocks). Einstein synchronization can always be done between
such clocks.

It is true that a sufficiently distributed set of clocks (say, Earth,
Mars and Venus) will not agree on the simultaneity of remote events,
but that lack of simultaneity can be exquisitely calculated, and even
used for navigation (see, e.g., the Sagnac effect).

And, of course, this is also orthogonal to the problem at hand, as
UTC, GPS time, TT, all  also experience from the same issues, and it
has nothing to do with leap seconds.

Regards
Marshall