.. and I work in a guvmint department where XP+Office2003 is the standard install image ...

I was doing leap second testing in the last month and I'm pretty sure that date
returns
23:59:58
23:59:59
23:59:59
00:00:00
as you go through the leap second addition
(Un)fortunately, not at work so I can't double check but a quick look at the date source code suggests that this is indeed
its behaviour on Linux.

You're right.
An application will see two 23:59:59 timestamps (in Linux anyway) because the
clock is stepped back by 1 s during an addition.

In ntp.c second_overflow() it says /*
    * Leap second processing. If in leap-insert state at the end of the
    * day, the system clock is set back one second; if in leap-delete
    * state, the system clock is set ahead one second.
    */
and at the time the leap second goes in
  case TIME_INS:
    if (secs % 86400 == 0) {
          leap = -1;
          time_state = TIME_OOP;
          time_tai++;
          printk(KERN NOTICE "Clock: inserting leap second 23:59:60 UTC\n");
          }
          break;
and in timekeeping.c it says
  leap = second_overflow(timekeeper.xtime.tv_sec);
  timekeeper.xtime.tv_sec += leap;
  timekeeper.wall_to_monotonic.tv_sec -= leap;
where xtime is the "current time"

The wall clock time is still useable if you also use adjtimex() (on Linux anyway) to check whether or not there is a leap second in progress. If you want to compute a delta for some event external to your application like a file update then you're going to have to use wall clock time. And you're also going to need a table of historical leap seconds if the event was a really long time ago.

"Assuming an average of one leap second per year, it would take 300 years to accumulate just a measly 5 minutes of difference." It's a bit faster than this because the tidal slowing of the earth;s rotation increases the discrepancy by about 1 ms per day per century (ie after 100 years, the average day is 1 ms longer, so you get an extra leap second every 3 years. And after 200 years, an extra leap second every 18 months and so on).

umm maybe you had better lay off the crack. 100 000 x $650 = $65 000 000.

Oops, now I see what you meant. When I said that GPS was not good enough for this application, I was referring to VLBI, not synchronizing a phone network.

Not quite sure what you're saying. GPS satellites do have good clocks on board - rubidium and cesium atomic clocks - and these clocks are steered from the ground by a very large ensemble of atomic clocks including hydrogen masers. The proBlem is transferring this to a ground station. The ionosphere and troposphere introduce short term noise that degrades timing references that you can derive from GPS. GPS broadcasts information that allows correction for these effects but this is of course via a model. You can average out some of the residual noise but you then want a good oscillator to flywheel on. The end result is an oscillator that is good to about 1 part in 10^12. CDMA base stations typically used to have a GPSDO ie a GPS receiver disciplining a rubidium or good quartz clock because of timing and holdover (how long you can run if GPS signals are lost) requirements. Disclaimer: I may or may not be working on a project connected with the SKA :-)

GPS does not provide a good enough time reference for an application like this. Typically you need a hydrogen maser; these cost about $300K. The problem is that GPS has pretty poor short term stability - about +- 20 ns at 1 s for a low cost timing receiver. Averaged over one day GPS gives you a decent frequency reference but to average, you need another oscillator like a rubidium atomic clock. The rubidium gives you better short term stability and then you improve its long term stability by comparing it with GPS and adjusting it. But a rubidium isn't good enough either for the application. Providing suitable timing references to a distributed system is an active area of research. The paper "Phase transfer ..." http://www.skatelescope.org/publications/ gives you an idea of the timing requirements.

The problem with dumping unwanted NTP traffic is that the clients do not necessarily respect ntpd's 'bugger off' responses like a 'kiss off death' packet. This has led to many problems with public NTP servers being swamped by traffic from poorly written NTP clients. Blocking some clients simply causes them to increase their polling rate !

BTW ISC simply hosts the ntpd project, it does not run it. ntpd is developed and maintained by David Mills, the author of ntpd, and a group of volunteers.