THE DIFFERENT ANSWERS ARE SEPARATED BY A LINE OF STARS








  In order to define intervals by the difference between timestamps,
  a linear timescale that progresses at a constant rate (ignoring
  relativity) is needed. That in itself isn't a problem because TAI
  can be used for that purpose. However, it is a problem that the
  mapping between TAI and UTC for times in the future is unpredictable.
  That effectively means that any system that needs to calculate
  intervals by timestamp differences has only the following options:
    - avoid using UTC for timestamps entirely (even in user interfaces,
      not just internally)
    - keep itself up-to-date with leap second decisions - which are
      decisions made by an authority, rather than a directly
      measurable physical quantity like TAI time.
  Neither option is particularly attractive when compared to the much
  simpler option of a fixed mapping between TAI and UTC. Increasing
  forecast times for leap seconds would not solve the basic difficulty.
 
	 	
 
*********************************************************************************
It is quite enough for us.
 
	 
 
	 	
 
         
 
*********************************************************************************
 Application of leap seconds in US SSBN fleet involves some risk of operator 
error resulting in unacceptable impact (this has happened in the past)
 
  
 
	 	
 
	 	
 
 
*********************************************************************************
    We use UTC as "universal time" from ship to ship, ship to shore, and
ship to air.  Leap seconds are cumbersome
and unnecessary for this purpose.  We believe that it would be better to use
TAI for general purposes and let those who need to approximate UT1 make the
adjustments.
 
  
 
*********************************************************************************
	We need to test the leap seconds when they happen.
 
 
 
 	 	
 
          
*********************************************************************************
        * forget a leap second in softwares has dramatic consequences.
        * introduces an unnecessary complication in the concepts  
 

*********************************************************************************
  What we have is not perfect, but it may be the best we can do to keep 
UTC and UT1 in sychn.
 
         
 
	 
 
         
 
*********************************************************************************
  The result of current definition is a discontinuous timescale.
 
	 	
 
 
*********************************************************************************
Because it is inconvenient.
 
	 	
  
*********************************************************************************
Too much work at our end for very little gain. 
 
	 
 *********************************************************************************
       Answer:
     Because time discontinuity causes a number of problems in handling
     time-stamped geophysical data such as seismic.
       Because time discontinuity caused by the leap second is very
disadvatageous for time-stamping continuous geophysical measurements such as
seismic.
 
   
 

*********************************************************************************
	I don't like the concept of leap seconds and I don't think they
	are necessary for anything important.
 
         
 	 	
 
*********************************************************************************
            Leap seconds cause a lot of pain and suffering for precise navigation 
using GPS,
  especially in conjunction with other systems that generally time mark with UTC.
Technically,
  it's just minor bookkeeping, but it always seems to get missed somewhere.
 
*********************************************************************************
  Occurence of a leap second is too frequent even it occurs every one year or so,
 and the adjustment for the leap second is a kind of extra work.
 
	           
Why bother to keep UTC within +/- 0.9 s of UT1?  If the tolerance were
relaxed to +/- 10 s, adjustments would be needed only about every 20 years
(at the present rate UT1 is drifting).  A tolerance of +/- 10 s would have
negligible  effect on sun rise/set times. The tolerance could even be
relaxed to +/- 1 minute, in which case a =B3leap minute=B2 might not even be
needed in the 21st century!
I DO favor retaining  UTC and keeping it somewhere near UT1, since civil
time should track the rotating  Earth.
 
 *********************************************************************************
  Discontinuity and ambiguity of time is very difficult to handle. 
 
*********************************************************************************
The few second corrections do not solve any significant problem and
creates many.
 
*********************************************************************************
It should be possible for a manufacturer to design an equipment, which handles 
UTC over a design life of 10 years, without having the user involved. This is 
not possible with the present UTC definition, where the possibility exists that 
every 6 months a new decision is made on a new leap second.
 
	 	
*********************************************************************************
 Generalized time arithmetic is impossible with UTC.  You cannot pack it into a
closed algorithm, you cannot compute it into the future, and you cannot figure it
out historically without providing detailed and updateable records.  For
calculations across long periods of time, you end up assuming UTC=UT1.  Most 
relevant computer software still assumes UTC=UT1 (e.g., spreadsheets).