THE DIFFERENT ANSWERS ARE SEPARATED BY A LINE OF STARS A change would probably result in changes to existing software ************************************************************************* Our whole clock and observing system is set up to use the existing system and it would be a real problem to change it all. ************************************************************************* There is a very specific definition of UTC which is useful by itself but also has been incorporated in many astronomical software systems. In the current situation, all users have a clear choice of time scale, depending on their particular needs; those that need a leap-second-free time scale can use TAI. If we were to do away with the leap seconds, we would turn UTC into yet another unnecessary clone of TAI. And if the method were changed (heaven forbid we change the definition of the second!) it would require very extensive and costly changes to the astronomical software that presently handles conversions between various time scales. ************************************************************************* The procedures for determining and disseminating UTC time are well established and well known. Any changes in these areas will certainly cause some substantial confusion, particularly for users not familiar with time scales and timekeeping. Software changes, sometimes substantial, may also be required depending on the any new method selected (although continuing UTC with no leap seconds will cause the least impact on any of the software I am familiar with, either in my current work in planetary geodesy and mapping, or in previous work in VLBI and Earth orientation itself). I will also add that the use of UTC without further leap seconds, after an initial period of confusion, may eliminate some problems and confusion for now. However at some future date when UTC (civil time) obviously becomes substantially different by minutes from solar time, a large adjustment in it will be needed, causing a great deal of confusion and problems - especially given the likely technical sophistication of our world (and indeed our solar system) by that date. A redefinition of the second, although possibly feasible, would also now or in the future cause similar large scale problems. I have seen no end of the problems caused by the changes in the length of the second in the late 1960's (and only a few weeks ago was dealing with that very problem myself in trying to understand the time scale used in spacecraft data from that period). In short, it appears to me that although changes can always be suggested and although it can be argued that the current method of UTC determination is not perfect, any changes in it would cause a great deal of confusion either now or (more so) in the future. ************************************************************************* There already is a continious time system (TAI) for applications where discontinuities cause a problem. ************************************************************************* The only reasonable alternative presented is the ellimination of leapseconds and abandon the astronomical relationship with civil time. But, once abandoned there can be no going back. Adding an adjustment some decades hence will cause problems that make the Y2K bug seem trivial. Most complaints about the current situation are due to failures of software development organizations to engineer solutions for time keeping. UTC is designed for civil time keeping. Alternatives are available for automated systems (for example GPS time). Smoothing over leap seconds and redefinition of the second are unacceptable alternatives. No software in existence today is likely to be able to handle such changes. The Y2K bug is trivial in comparison to the problems that would be introduced by changing the second or adding in some kind of smoothing function at leap seconds. ************************************************************************* > In the next hundreds of years we will arrive to a leap day otherwise. Other types of time-definitions can be used if you do not want leaps. ************************************************************************* TAI is already available for those who require a timescale free from leap seconds. ************************************************************************* The present system seems to work within the limits of our use. ************************************************************************* UTC as currently defined provides a reasonable compromise between a high-precision atomic time scale and one kept in step with the Earth's rotation. If leap seconds prove inconvenient for a specific application, then an alternative scale (such as TAI) can always be used. (In other words, one doesn't HAVE to use UTC if other currently-existing time scales are more useful for a specific application.) I think the LEAST desirable alternatives from the above list would be: (c) Smooth over leap second step. I'm not quite sure how this would work, but it sounds like it would make it very difficult time events accurately in the vicinity of a leap second. (d) Redefine the second. This would create a horrible mess throughout the physics community, and really wouldn't even solve the basic problem: that of keeping an accurate atomic time scale in step with the irregular rate of the Earth's rotation. ************************************************************************* The current method of UTC determination is suitable to our usages in geodetic astronomy, geodesy and navigation ************************************************************************* > The system works fine as it is. > ************************************************************************* There is existing equipment which already takes into account the leap seconds. If the determination of leap second - algorithm or frequency, changes, then many software packages and all fielded units will need be adjusted. An analogy would be to eliminate leap years - Think of all the software out there which already handles leap years with a predetermined algorithm! ************************************************************************* SUFFICENT EXPLANATION AND TECHNOLOGY EXISTS TO MAINTAIN CURRENT SYSTEM ************************************************************************* Any change would necessitate rewriting large amounts of software with little or no benefit in return. ************************************************************************* The present system is a good compromise between UT1 and TAI, allowing civil time (UTC) to remain within 1 sec of UT1. Civil timekeeping needs to stay close to UT1 to avoid having the time get too far out of step with earth rotation. ************************************************************************* The necessity for a change has not been established. ************************************************************************* In good logic the question should be reversed, and the onus put on those advocating for change: why is an alternative solution needed? If I am guessing correctly from the very limited information that is provided, the issue seems to be that some users would want a continuous time scale. If that is indeed the case such a time scale already exists, TAI, and those people should just use it rather than push for the introduction of another one that's simply offset by 30 seconds or so. I have no particular objections to the eventual phasing out of UTC in favour of TAI, but strong objections to changing the meaning of a well understood quantity. ************************************************************************* Because the alternatives are worse: 4aa Eventually drifts too far, like the Julian calendar. At some point a "whopping" correction is needed. It's a good thing there weren't any computers in Sep-1582. :-) 4ab In certain contexts, yes (see below), but UTC is better for real "time of day" uses. 4b Unless the tolerance becomes infinite, it only postpones the problem it's trying to solve. Meanwhile various methods of indicating DUT1 need to be changed. 4c Doesn't really solve the problem of using UTC to measure intervals; it just trades one type of problem for another. 4d Gee, this is what the whole system was created to avoid in the first place. :-) Granted, 1900 was probably not the best choice of references for the SI second, but changing it now would be worse. ************************************************************************* It is working well, for me, as it is. ************************************************************************* There is nothing wrong with the current system of keeping time in UTC. Most users, except those who require precision computation, do not know or care about the discontinuity of UTC by the leap second. Any change will impose software changes to the all the current and future UTC computation for satellite ground and space control. The very few people who understand time scales may not be able to direct the software changes, and this is going to be a problem for many satellite projects. ************************************************************************* It is important for users of server-based applicaitons to have a time base that has a close, fixed relation to local time, to an approximation of a few seconds. ************************************************************************* The present system works well for astronomy: a. There is sufficient warning of a leap second b. Adjustments are not too frequent. c. The history of leap seconds is well documented. d. At SAAO data time stamping is one second out for the rest of the night after the introduction of the leap second but all observers are aware of this and correct the time accordingly. The leap second is introduced into the system the following morning. e. For international collaboration on astronomical observations a full second adjustment is more visible than smaller adjustments when correlating data. f. The effect of calculating sidereal time from UTC for telescope pointing is minimal. ************************************************************************* UTC is an accepted definition for scores of spacecraft data archives; changing it now will only introduce confusion in the future. If a new standard is needed for GPS or other applications, create a new standard; don't interfere with an existing one already in use. ************************************************************************* It is convenient to have UTC be close to UT1 for low and medium precision astronomical applications. Those who want to avoid leap seconds should simply use TAI instead of UTC; redefining UTC is not necessary. If UTC were redefined to ignore leap seconds, while maintaining the current definition of the second, the drift of UTC away from UT1 would not be a significant problem for civil purposes. After all, we sometimes ignore a difference in longitude of ten degrees or more from the start of a time zone, and we shift our clocks by an hour for half the year. On the other hand, much astronomical software takes advantage of the fact that UTC and UT1 are nearly the same. ************************************************************************* We thank you for including us on your open request for comments. As a way of introduction, The MITRE Corporation provides systems engineering support to Electronic Systems Center (ESC)/NDW. ESC/NDW, among other systems, is responsible for the acquisition and sustainment of the Ground-based Electro-Optical Deep Space Surveillance (GEODSS). This sensor system is part of the Space Surveillance Network. Among other missions, this command has the responsibility of acquiring and maintaining the ground based sensor systems that detect and track the 10,000 or so man made objects now orbiting the Earth. UTC is used by these sensors and is integral in maintaining the positional / temporal database. Changes to the way UTC is corrected and / or maintained will more than likely impact our algorithms and methodologies. Our accuracy must be maintained. We would like to open a dialog to determine what solutions you are considering implementing. If UTC will be maintained in its present format for the foreseeable future, and with equivalent accessibility, then we have no need for discussions. However, if you are planning on changing it, then we would like to learn in detail what the proposed changes are and their implementation schedule. If possible and appropriate, and if the changes proposed will have significant impact to our systems, we would like to take part in the discussions and contribute to the formulation of the redefined UTC. Again, thank you very much for your e-mail and we hope our request is not presumptuous or naïve. We hope to contribute to a mutually beneficial outcome. ************************************************************************* Because it is really easy as it is to derive TAI or GPS time from UTC, and to check that the result is acccurate ************************************************************************* Works well now for us, lots of software supports it and assumes it. Fine for other people (eg nav community) to use TAI if they prefer - that's no reason to stop defining UTC. My sense is that the nav community don't like leap seconds - so let them use one of the preexisting timescales that doesn't have them, like TAI or TT, rather than making UTC redundant with one of these. I guess I don't mind if you really want to rename the timescales, creating a new name UTA (UT Adjusted) for what we now call UTC, and relabelling TAI or TT as the new UTC. It'll cause confusion, but as long as a timescale equivalent to current UTC continues to exist I can live with it. The net effect of such a change would be to make TAI the civil timescale. On ecological grounds this can be criticized for further decoupling the rhythms of human life from nature; on pedagogical grounds it is unfortunate in removing a regular opportunity to educate the public about the irregular rotation of the Earth. ************************************************************************* Not yet. ************************************************************************* > > > I think there is a need both for a contineous time (GPS/TAI) > and a time linked to the mean sun (UTC). The leap second concept > is so simple that even I can understand it an implement it in my > programs, when required. Normal people doesn't bother (and > if they do, - they can also understand the concept). > ************************************************************************* As presently the difference UT-UTC is less than 0.9 second, for many purposes this difference can be neglected. Prediction ephemerides simply can be made in UT. But that will no longer be possible if leap seconds are no longer introduced. Moreover, introducing a "new" UTC will complicate things. Consider for instance the calculation of solar eclipses or occultations: now we have to use both Dynamical Time (for the calculation of accurate positions of Sun and Moon) and UT (to calculate the local hour angles). If the new UTC is introduced, that will be a *third* time scale which will be necessary to take into account. As another example of the complications which would be introduced, consider a list of special phenomena calculated for a long period, for instance from 1000 B.C. to A.D. 3000. What time scale should be used here? (1) If we use UT, then after t= he year 2005 the times will differ from the "actual" UTC. (2) If UTC is used for the whole= list, then we will have the strange situation that old times are expressed in UTC, stupid of course, as if the old Babylonians had time signals at= their disposal! (3) And if we use UT before 2000 and UTC after 2000, then there will be a discontinuity at A.D. 2000. = ************************************************************************* Our current processes are geared to using the current method of occasionally adjusting via insertion of whole Leap Seconds. We do not wish to adjust our processes unnecessarily. The curent method works well for our purposes. ************************************************************************* ************************************************************************* The needs for navigation or telecommunication are covered by time scale with no leap seconds, ie TAI. Exists CCTF recomendation to use continued scales in this applications. ************************************************************************* I think it solves the problems it was intended to solve just fine. Many of the complaints I have heard about it are based on a lack of understanding of how difficult the problem really is. Please see my comments below. ************************************************************************* The current UTC definition works well. Our existing computer systems work well as the NTP deals with leap seconds just fine. The current system, with DUT1 corrections works well for our robotic telescope drives as well. ************************************************************************* We distribute and use UTC for tracking and instrument calibration. The leap second keeps UTC close enough to sidereal time for our calibration purposes. ************************************************************************* Astrophysical and other scientific measurements rely on the basic properties of time as determined, e.g., by an atomic process. Civil institutional infrastructures do not typically have such a need for extreme precision. It is best to accommodate civil time-keeping standards that are based on the rotation of the Earth, whose angular velocity is continually changing with time, by introducing discrete steps in the relative time keeping at well defined periods of the year. ************************************************************************* Our clocks & time servers works automatically ************************************************************************* The current system works. The engineering problems created by leap seconds are not significant problems. The current system meets the needs of nearly all users, and maintains and illustrates the relationship between astronomical time and atomic time, which is important. I am also opposed to the distribution of TAI as an operational time scale. This would increase, instead of reduce, the confusion about time scales. ************************************************************************* Been using the old system too long ************************************************************************* Most operational satellite orbit determination processes rely, either directly or indirectly on stations located on the rotating Earth. For this reason, the quantity 'UT1-UTC' is an important piece of information that is well defined and well understood by system operators and the large operational software packages in use at satellite ground stations. Any change in the current method of dealing with UT1-UTC would require significant software modifications, testing, documentation changes and training of the system operators. The expense associated with these changes would be significant and there would be no tangible benefits for these systems if the current procedures were to be changed. If changes such as a-e above were to be implemented, we would merely be dealing with UT1 vs UTC in a different, more complicated way. ************************************************************************* It is very useful for us that civil time (UTC) tracks UT1 to within a fraction of a second. Our observatories maintain atomic time which has a stepped-constant offset from UTC, the application of DUT1 then produces UT1 from which we may compute local sidereal time. We have developed systems to manage this automatically. Some of our control software contains graphical celestial displays for which UTC is an adequate approximation to UT1. Therefore we can conveniently use the system time reported by the computer operating system. ************************************************************************* UTC combines the advantages of a physically well defined precise and smooth time scale (from TAI) with the natural circumstances that govern every day's life (earth rotation). Both should be kept in a well defined relation to each other - that can be done with a leap second. ************************************************************************* For civil use, it is important that UTC stay within 1 sec of UT1. Difference could grow very large if there were no leap seconds, because of changes in earth rotation rate. For scientific use it is very important that the UTC rate be the same as the atomic time (TAI) rate. Should not redefine the second to be a different number of cesium cycles. Whatever choice was made would soon be wrong as the earth rotation rate changes. ************************************************************************* Maintain UTC close to UT1. TAI exists as a system free of leap seconds for those who need it; if the UTC leap second is abandoned then it will just be another TAI, with an arbitrary number of integer seconds offset. ************************************************************************* The current system works for me.. Changing the system will require software modifications. ************************************************************************* I think it would cause many problems with the existing devices, which would appear determining time incorrectly. Moreover, redefinition of UTC would not make the situation easier, because of we already have leap seconds era and are forever bound to take it into account in any future time calculations. ************************************************************************* Will cause confusion in the near future. There are already defined time systems without leap seconds so there will be minimal benefit in the future. ************************************************************************* # The way it presently is, UTC fulfills its definition and requirements of flowing along TAI while keeping some track with solar time. New needs, if enough widespread, should give rise to a specific time scale. ************************************************************************* The approach does not make any problems for my work. So I don't believe it is necessary to change it now. ************************************************************************* > IT WORKS FOR ITS INTENDED USES. RATHER THAN CHANGE IT PROVIDE FOR A NEW ALTERNATIVE (AND LET THEM COMPETE TO SEE WHICH WINS OUT IN THE LONG RUN). ************************************************************************* Using TAI or smoothing leap second steps would disrupt existing systems for processing and exchanging seismological data, leading to software development costs and almost certainly leading to significant errors in earthquake parameters and other seismological data due to errors in exchanges between agencies. Using UTC without further leap seconds would eventually lead to problems communicating seismological information to the public. Increasing the tolerance for |UT1-UTC| is preferred among the alternatives suggested because it could be used without modifying our existing processing (thus no additional cost) or data exchange (thus no additional risk of error). Provided that the new tolerance was no more than several seconds, there would be no important problem communicating with the public. ************************************************************************* Easy adjustment of whatches, no recalculation from UTC to TAI and vice versa in short periods (between leap seconds settings), easy recalculation from UTC to TAI and vice versa for longer periods, similar methods in calendar keeping. ************************************************************************* Anyone who wishes to utilize a time system without discontinuity can use TAI or GPS time. Prior to 1972 the drift rate between UT1 and UTC was also modeled. But, this did not alleviate the need for UTC discontinuities and also introduced rate discontinuities. The IERS could publish UT1-TAI in addition to UT1-UTC. Smoothing over the leap second would just introduce new problems. ************************************************************************* The publics have just been familar with UTC although it was actived in 1972. Even now someone still say GMT. The stable system give more confidence to the public. ************************************************************************* The publics have just been familar with UTC although it was actived in 1972. Even now someone still say GMT. The stable system give more confidence to the public. ************************************************************************* Although not graceful, this method does have an exact procedure which can be followed with sub-second accuracy. ************************************************************************* We accommodated to this definition and developped our products in consequence. ************************************************************************* Changing the determination method of UTC would require major changes to a large amount of astronomical data analysis software which currently assumes that UTC is a good approximation to GMT. ************************************************************************* a) I prefer constant offset between TAI and UTC. b) I prefer to keep UTC close to UT1. c) Adjustments to UTC approximately every 18 months are acceptable. ************************************************************************* Only (a) is a possibility, and I'll deal with that last. b) Will break some software and encroach on navigators' accuracy. Then when eventually the accumulated leap seconds are applied, everyone will have forgotten how to deal with them. c) Going back to rate corrections will break software and be even more inconvenient than leap seconds. d) Would cause astronomers to be reviled by all other scientists. e) A low-accuracy web- and NTP- based GMT=UT1 service would satisfy most users who want a continuous scale. Regarding option (a), there are decisive reasons against: * There are many assumptions built into software, practices, even our culture that mean solar time and civil time are linked. Problems would continue to surface for decades and would cost far more than continuing leap seconds. * Software that assumes |UT1-UTC| < 0.9s would break. * Tens of thousands of marine navigators would have to be equipped with revised sight reduction procedures and re-educated. * Breaking the link between astronomy and time would damage astronomy. Leap seconds are the one time when the public glimpses what's involved in providing time services. * It is up to groups who have adopted UTC in ignorance of leap seconds to change their practices. They should not expect the rest of us to do things their way (with attendant disadvantages). The proposal for a low-cost low-accuracy GMT=UT1 service would give such groups a way out, as would adopting TAI. Groups with a very serious problem, such as GLONASS, could perhaps adopt a private timescale called "UTC2000" or "Moscow2000", freezing the current offset with respect to TAI. This is, after all, no different from "GPS time". ************************************************************************* This meets our present requirements. Psesent system satifies the our requirement and also we used to t for long time. ************************************************************************* This is a practical correction for time. ************************************************************************* The present method is transparent, understood and with modern IT is not a problem so long as a minimum of 6mth notice is given. ************************************************************************* I DEAL WITH COMPUTER SOFTWARE THAT USES THE CURRENT, DISCONTINUOUS METHOD. TOO MUCH SOFTWARE WOULD HAVE TO BE CONVERTED. ************************************************************************* The current method is sufficient for many hundreds of years. The alternatives that are proposed are shortsighted and ignore the responsibility the precision timing community has to provide the best possible civil time scale. ************************************************************************* Too much investment of software and knowledge to change. ************************************************************************* Option d above is just plain insane and smacks of the kind of option that is so bizarre that by its mere proposal the proposers hope to make it plain that their preferred option for change is better than some other changes that might be implemented. But by that very proposal it becomes clear that the proposers are set upon making some change. Astronomical telescopes are controlled by hardware systems which tend to have lifetimes of about 30 years. This is the natural timescale because the control systems are usually designed by an engineer at the prime of his lifetime, and after implementing the system that engineer typically cares for it until the time of his retirement. UCO/Lick Observatory is, even now, designing the replacing its 25 year old telescope control system. Any change to the manner of operation of UTC which happens within the next 30 years will require this system to be modified. The director of Lick Observatory will not thank anyone who changes the way the way UTC works and causes him to reallocate precious observatory manpower resources before the lifetime of this new system is complete. ************************************************************************* There are many computer programs to calculate eclipse and occultation predictions which are distributed to many amateur observers. As far as I know, all of such programs take into account the difference between UTC and TT, but do not take into account the difference between UT1 and UTC. If |UT1-UTC| becomes larger than, say, 1 sec, predictions made by such programs will have large errors so that observers of the phenomena (especially lunar grazing occultations) will fail in their observations. Before 1972 the length of the UTC second changed frequently, so the conversion from UTC to a unform time scale during that period is complicated. If the length of the second is redefined again, it would also add another complication to the conversion, so I strongly oppose to the rededinition of the second. ************************************************************************* OUR C2 SYTEM, CALLED THE COMMAND AND CONTROL SEGMENT (CCS),IS IN USE BY SEVERAL SPACE OPERATIONS SQUADRONS (SOPS) AT THE AIR FORCE SATELLITE CONTROL NETWORK (AFSCN). CCS SOFTWARE DESIGN IS ARCHITECTED TO DISPLAY TIMES IN UTC AND TO USE PERIODIC LEAP SECOND ADJUSTMENTS WHEN THEY ARE DECLARED BY IERS. CCS EXISTING DESIGN COULD ACCOMMODATE OPTION 4.a.1 (UTC without leap second) OR OPTION 4.b (Increase tolerance for UT1-UTC) WITHOUT SOFTWARE MODIFICATIONS. OPTIONS 4.a.2 (Use TAI), 4.c (Smooth over leap second step) OR OPTION 4.d (Redefine the second) WOULD REQUIRE EXTENSIVE SOFTWARE MODIFICATIONS (ENHANCEMENTS). THE CURRENT SUSTAINMENT CONTRACT FOR CCS MAKES SUCH SOFTWARE ENHANCEMENTS PROHIBITIVE FOR OUR AIR FORCE CUSTOMER, AIR FORCE SPACE COMMAND - SMC/CWSND. ************************************************************************* I see no good reason for a change. Also, doing so would introduce a major backward compatibility problem with an uncounted number of mainly (but not exclusively) astronomical software packages! If certain projects are unable to deal with the leap seconds in UTC they should adopt another (continuous) time scale for their purpose (as e.g. the GPS system has done). ************************************************************************* All the alternatives are worse (see remarks). ************************************************************************* Because the procedure has worked satisfactorily in the past decades. ************************************************************************* The current method is satisfactory. ************************************************************************* customers are currently used to current configuration. ************************************************************************* My comments in my response of 11 December 1999 to the previous UTC Questionnaire about legal issues still stand. UTC is used for time signals on which civil time is based, but in many parts of the world legal time is not based on UTC. In the UK it is based on "Greenwich mean time". In the EU Summer Time Directive the start and end times of summer time are expressed in terms of GMT in the English language version, but in terms of UTC in the Danish language version. As long as there is a 0.9s tolerance for |UT1-UTC|, there are unlikely to be legal problems; this timescale is conveniently short in terms of human actions and reactions. (For example, US standards for traceability of financial transactions only require clocks to be traceable within 3 seconds, so leap seconds are not currently relevant for that purpose.) If the time were to increase to a scale of ten seconds of more, and certainly if it were to increase to a minute or more, the likelihood that a court would need to consider the difference increases, and although not a lawyer I believe that English courts in such a case would be forced to conclude that whatever "Greenwich mean time" really means, whether it means UT0 or UT1, it cannot mean UTC if that diverges substantially (and probably cannot mean UTC anyway, but with a difference of 0.9s it is very unlikely to come to court, since the courts will only consider genuine disputes). It would then be likely to take more decades of legal time differing from civil time signal time before the matter would be addressed legislatively. With reference to the specific proposals: (a) Implying divergence of UTC from UT1 would I expect cause legal problems, the likelihood of these increasing in proportion to the divergence. (b) A small tolerence (but bigger than 0.9s) would be unlikely to cause problems, though any increase would still increase the risk of such problems. The benefits from increasing the tolerance seem doubtful. (c) If anything, smoothing over the step would reduce rather than increase legal problems. However, I would expect this to cause more complexity in software than simply having leap second steps, and not to be a desirable method. (An alternative timescale, algorithmically related to UTC but with smoothed steps, could nevertheless be defined for those purposes for which it is convenient; e.g., it could be a recommended timescale for computer clocks on general-purpose computers to follow around the steps.) (d) A redefined second, reducing the difference between UTC and UT1, would have an uncertain effect on legal problems. Unlike other units, where the SI definitions are written into UK law, there does not seem to be a definition of the second in UK law. I do not however consider redefining the second for the convenience of civil time to be a good scientific move. Units should be redefined when advances in science or technology mean that the old definition is measurably ambiguous or a new definition lends itself to more accurate measurement, and then should be defined so that within the limits of measurement the definitions yield the same value. ************************************************************************* Insert 1-second leap seconds on dates predicted by some simple formula, based on a model for the estimated slowing of the Earth's rotation. |UTC-UT1| would grow to more than 1 second, but would remain much smaller than if leap seconds were discontinued. See figure 5 of [1] (the line marked "1 second at predicted intervals"). The conclusion there is "This shows that the difference between UTC and UT1 could reach 10 to 20 seconds" [up to 2500 AD]. If the conclusion is correct then the UTC-UT1 difference would not be a significant practical problem. Advantages: - would solve the main problem of predictability. - there would be a well-defined mapping between TAI and UTC for all past and future times. That also means that the precise interval between any timestamps represented as (UTC-time, during-leap-second-flag) could be calculated. - maintains the difference between UT1 and UTC small enough not to cause any practical difficulty for applications of UTC. - existing software/hardware systems can treat the predictable leap seconds as if they were decided using the current procedure (especially if the dates are still restricted to the end of June and December). Disadvantages: - not as simple as discontinuing leap seconds entirely. - systems that assume |UTC-UT1| < 0.9s can break (but that should not be much of a problem if sufficient advance warning is given, and it is also a disadvantage of most of the other options). If this option is not taken, my next preference would be "UTC without further leap seconds".