Re: FreeBSD handles leapsecond correctly

In message <20060103101713.GI42228_at_cirb503493.alcatel.com.au>, Peter Jeremy writes:

>Timing products are obviously a special case.  I still stand by my
>"common" statement.

This is a very nice position to take, but how do you plan to educate
all the people who need to know, how to tell the difference between
a "common" and a "timing" requirement ?

How do you even define the difference ?

If you start to analyse things, you soon end up with the with same
conclusion that Dave Mills and Dennis Ferguson did many years ago:
If it is connected, it is a "timing system".


The biggest problem about the leapsecond debate is that very few
people know enough about what they are talking about.

The astronomers know far too little about modern computing.  They
think that their instruments will be more expensive to modify than
it will be to teach all other computers to handle leap seconds
properly.

The "time lords" are in the same category, they havn't realized
that other kit than their clocks work in the sub-millisecond regime
for long periods of time.

The entire IT business, as such, knows far too little about time
and virtually nothing about leapseconds as evidenced by the POSIX
text and Windows handling of time.

The press will print anything which makes a good headline, without
trying to understand the underlying subject matter or its implications.


There are two fundamental issues:

1. POSIX is lame.

2. Leapseconds are only announced 3-6 months in advance.


Fixing POSIX will mean that applications can precisely calculate
time intervals into the past, but still not further than 3 months
into the future.  Neither of which seem particularly important for
the majority of computer users.

But fixing POSIX does not solve the second half of the problem
and may in fact only make the consequences of it worse, as programmers
will then have the option of taking leap seconds into account, but
may be running without up to date leap second tables.

It's the unpredictability and short notice of the leapseconds that
is the fundamental problem.

The following proposals have been aired:

A)  Abandon leap seconds.

	This makes POSIX correct and computer timekeeping comes
	down to being in sync or not being in sync.

	The Sun will slowly (over centuries) drift across the sky.

	The easiest way to compensate for that is to skip timezones
	by not "falling back" from DST or similar.  Such changes
	can be announced 100 years in advance and should therefore
	pose little trouble for computers.

B)  Predict leap seconds further in advance.

	This increases the |UT1-UTC| tolerance and the astronomers
	will have to cope.

	Provided that the notice becomes long enough, 10 years as
	a minimum, computing problems will mostly disappear, provided
	operating system suppliers pay attention to it.

C)  Make leapseconds smaller and more frequent

	Make the individual steps smaller (10 msec ?) and more
	frequent (every month ?) and therefore less dangerous at
	the expense of higher frequency.

	Again, provided we get to know far enough in advance (10 years
	or more) this is workable for computers.


And finally some anti-FUD:

"Abandonning leap seconds means the sun will rise at night and it will
be dark during the day!"

	No, a simple change of timezones will prevent this.  Changing
	timezones is about as much trouble as changing daylight savings
	time, something which the US congress has no qualms doing.

"It is very important for people that the sun is in south at noon"

	Less than 1% of the earths population has that priviledge now.

	The majorty lives with timezones that put the sun anywhere 
	from -15 to +15 degrees from south at noon, in some notable
	cases like China, up to +/- 45 degrees or more.

"We don't know what will break if we drop leap-seconds"

	We know very well what can break:  Only systems which relate
	the position of extra-terrestial objects to UTC time can break.

	These devices are called antennas and telescopes and they are
	operated by scientists and technicians who should be more than
	able to figure out how to deal with this.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.