Re: [LEAPSECS] Torino presentation

From: Neal McBurnett <neal_at_BCN.BOULDER.CO.US>
Date: Tue, 27 May 2003 11:59:26 -0600

Excellent presentation, Marcus!
Excellent argument, Ed!

I hope the folks at Torino recognize the need for a much more open
process, broader participation and further discussion, and stick to
the careful, logical, approaches that Marcus and Ed recommend.

Neal McBurnett http://bcn.boulder.co.us/~neal/
Internet2

Marcus wrote:
> http://www.cl.cam.ac.uk/~mgk25/c-time/torino2003/

On Tue, May 27, 2003 at 06:00:14PM +0100, Ed Davies wrote:
> Ed Davies wrote on 2003-05-27 13:56 UTC:
>
> > Slightly more relevantly: I was a bit surprised that you did not
> > put more emphasis on the need to distinguish the different types
> > of time scales an application program can ask for from an operating
> > system, as your ctime library highlights.
>
> Markus Kuhn replied:
>
> > I had thought about this, but I concluded that this would be out of the
> > scope of the ITU-R, who are in the business of standardizing time signal
> > broadcasts, and not operating system APIs.
>
> Fair point, but if I might summarise what I think is a
> slightly generalised version of your argument:
>
> 1. There's no single perfect timescale for all application
> requirement combinations (keeps close to UT1, SI seconds,
> 86 400 second days, etc) - because some combinations of
> requirements are contradictory.
>
> 2. We need to make up timescales for specific combinations
> of requirements not catered for by existing timescales
> (e.g., UTS if you are willing to relax the SI second
> requirement but don't want to use UT1 for sensible
> reasons).
>
> 3. We have to live with lots of timescales - please fix the
> radio signals to make this easier.
>
> You cover points 2 and 3 well but I think rather assume point
> 1 which is a pity as you are in a good position to illustrate
> it. If this point was already well understood then perhaps
> there wouldn't be the same pressure to "fix" UTC in the forlorn
> hope of somehow making it perfect.
>
> Ed.
Received on Tue May 27 2003 - 10:59:39 PDT

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:54 PDT