[LEAPSECS] alternative to smearing

Wed Jan 11 18:04:45 EST 2017

Kaye and Laby (Tables of Physical and Chemical Constants, 15th Ed., 
1986, Longman - G.W.C. Kaye and T.H. Laby - ISBN 0-582-46354-8) states 
that the year for which a mean solar day is 86,400.003 SI seconds was 
circa 1984. According to the given long term rates of change and 
assuming that this day length is exact, then in 1900 the mean solar day 
would have been around 86,400.00132 seconds and in 2000 would have been 
around 86,400.00332 seconds.

On 11/01/2017 22:38, Richard Clark wrote:
> Just to clarify--
> The changing length of the solar day affects the number of days in
> a year but not the actual length of the year.
>
> The earth is not near resonance with any other major solar system
> bodies so variations in the actual length of the year will be small
> and of long period. This remains to be quantified from references I
> don't have handy. For the next several million years there should be
> no overall trend for lengthening/shortening of the year.
>
> By 1e9 years solar mass loss may have been sufficient to produce a
> noticeable increase in the length of year. It's not out of the
> question that spin-orbit coupling between earth-moon system and sun
> should be included in attempts to model the future over that time scale.
>
> Richard
>
> On Wed, 11 Jan 2017, Robert Jones wrote:
>
>> Having followed some of the arguments in this thread:
>>
>> For the very long time as the length of the day increases, leap 
>> seconds are imperative as they will become progressively more common 
>> and archaelogists may curse those that don't use them. There might be 
>> a case for temporarily discontinuing them until computer systems 
>> become sufficiently advanced to handle all the changes automatically 
>> in perhaps another 50 years.
>>
>> In a similar vein, leap days will become progressively less frequent 
>> as the length of the day shortens,
>>
>> There was never an AD 0 in either the Julian or Gregorian calendars, 
>> the concept of using zero in counting scales was developed in Asia 
>> and adopted by the West many centuries later.
>>
>> (I hope the formatting comes across OK - if not don't bother to read 
>> further - Robert)
>>
>> I have developed a formula to determine the effect of combined 
>> increase in day length and decrease in year length. It calculates 
>> tropical year lengths measured in units of the mean solar day of the 
>> date under investigation. (I hope the formatting comes across OK - if 
>> not don't bother to read further - Robert)
>>
>>
>> 0.0000061 days per century decrease in year length. This is mean 
>> solar days of 86,400 SI seconds per Julian year. For these purposes, 
>> the Julian year and tropical year can be assumed to be the same, 
>> because the current discrepancy is about one part in a million, so 
>> the effect on the factor 0.0000061 is well below the level of 
>> accuracy in its specification. The effect of the difference between 
>> the current mean solar day and 86,400 seconds is also well below the 
>> level of accuracy of the factor. These assumptions are true provided 
>> that the equation is used to work out projections from dates close to 
>> the present, otherwise the factor must be adjusted appropriately.
>>
>> units are tropical years, mean solar days and SI second
>>
>>
>> a = no. of years ahead (positive) or past (negative)
>>
>> b = current no. of days per year (365.242193)
>>
>> c = decrease in year length per 100 years (0.0000061 days)
>>
>>         d = current day length in seconds (86,400.003 seconds in 1984)
>>
>> e = increase in day length per 1000 years (0.020 seconds) - this 
>> varies according to various factors such as core/mantle changs, ice 
>> ages and tectonic plate rearrangemens, plus major meteor impacts
>>
>>
>> days/year = (b - (c/100 * a)) * (d /(d + e/1000 * a))
>>
>>        days/year = (b - (c * a/100)) * (d /(d + e * a/1000))
>>
>> (The second form suits my spreadsheet better, as it reduces the 
>> roundings problem with the divisions.)
>>
>>
>> A more comprehensive formula from the more mathematically capable 
>> would contain factors for changes in the rates of change if any, and 
>> would also accommodate factors for the Milankovitch and other 
>> possible cycles. Incorporating these cycles would require a reference 
>> to a specific base date for their synchronisation.
>>
>>
>> A list of date related future events follows:
>>
>> (I have left a few dates of past events in the list for interest and 
>> to illustrate the types of problem that can arise or need 
>> consideration.)
>>
>>
>> A.D. 1999 August - first GPS rollover, repeated nearly every nineteen 
>> years, the next will be in A.D. 2019, I don't know whether GLONASS 
>> has similar peculiarities.
>>
>>
>> A.D. 1999 - various dates that may cause problems with nines in date 
>> fields
>>
>>
>> A.D. 2000 1st January, etc - main Y2K rollover problem
>>
>>
>> A.D. 2000 28th February, etc - first leap year of new millennium
>>
>>
>> A.D. 2000 31st December, etc - first year end of new millennium, some 
>> may argue that it should be 2001
>>
>>
>> A.D. 2001 28th February, etc - first non-leap year of new millennium
>>
>>
>> A.D. 2004 28th February, etc - second leap year of new millennium
>>
>>
>> A.D. 2019 6th April - next GPS rollover, they occur every 1024 weeks, 
>> as GPS is a "true" timescale it does not have leap seconds, so there 
>> is a slight drift from UTC.  (Probably fixed by now)
>>
>>
>> A.D. 2038 - older UNIX systems may have a roll over problem, while 
>> current redevelopments are in progress to prevent this occurring, 
>> there may still be residual problems
>>
>>
>> A.D. 2100 - about two leap seconds per year
>>
>>
>> A.D. 2100 - second century of new millennium (not a leap year)
>>
>>
>> A.D. 2132 - count of Modified Julian Days exceeds 99,999.
>>
>>
>> A.D. 3268 - first Julian period of 7980 years ends
>>
>>
>> A.D. 4000 - at current rates of change this should not be a leap year
>>
>>
>> A.D. 4595 - count of Modified Julian Days exceeds 999,999.
>>
>>
>> A.D. 10000 - probable rollover problem similar to Y2K, if the 
>> expected automated computer systems don't resolve it in good time
>>
>>
>> A.D. 10000 - about sixty leap seconds per year, by now it would 
>> probably be inadvisable for non-scientific applications to pretend 
>> they don't exist.
>>
>>
>> A.D. 22,378 - Julian days exceed 9,999,999.
>>
>>
>> A.D. 50,000 - about one leap second per day
>>
>>
>> A.D. 1,900,000 - 365 days per year
>>
>>
>> A.D. 7,800,000 - 364.25 days per year
>>
>>
>> A.D. 70,000,000 - sixty one seconds per minute
>>
>>
>> A.D. 1,000,000,000 - seventy five seconds per minute
>>
>>
>> A.D. 1,000,000,000 - 250 days per year
>>
>>
>> A.D. 1 billion to 6 billion - Sun may be a red giant, rendering Earth 
>> uninhabitable, sources vary as to when this may occur, but agree that 
>> it will.
>>
>> ************************************************************************************************ 
>>
>>
>> Robert
>>
>>
>> On 09/01/2017 12:41, Preben Nørager wrote:
>>>
>>> On Tue Jan 3 14:18:52 EST 2017, John Sauter wrote:
>>>
>>>
>>> "I regard leap seconds as a reasonable compromise between the needs 
>>> of civil time and of science. Civil time needs a clock that tracks 
>>> the days and the seasons. Science requires a clock that measures 
>>> time in precise intervals. UTC provides both, using leap seconds to 
>>> keep atomic time synchronized with the rotation of the Earth."
>>>
>>>
>>> I think there is something wrong with that argument. Civil 
>>> timekeeping holds both a clock, and a calendar. The calendar track 
>>> the seasons, while the clock track the time. If it is to be said, 
>>> that the clock track the days, it is important to notice the 
>>> difference between apparent time, and mean time. The clock track 
>>> either the sun (apparent time), or the seconds (mean time).
>>>
>>>
>>> When the Nautical Almanac in 1833 substituted mean for apparent 
>>> solar time, an important step was taken. From now on chronometry was 
>>> to rely on mechanical clocks, and with the invention of atomic 
>>> clocks, the tracking of the 24-hour day (86400 international 
>>> seconds) can now happen without any daily tracking of the sun.
>>>
>>>
>>> The question really is whether the calendar needs the daily tracking 
>>> of the sun or not. And the answer to that question obviously depend 
>>> upon which calendar we want!
>>>
>>>
>>> I think the disagreement about leap seconds, really is a 
>>> disagreement about which calendar to use for civil timekeeping. If 
>>> we agree to use the proleptic gregorian calendar (ISO 8601) there is 
>>> really no need for leap seconds. That calendar track the seasons 
>>> well, and with the slight modification, to add the additional rule 
>>> that years evenly divisible by 4000 are not leap years, it would 
>>> track them even better.
>>>
>>>
>>> Leap seconds are really only a need for those who do not want to see 
>>> the proleptic gregorian calendar become universal. For instance for 
>>> those who want to use the julian period, as the basis for one 
>>> calendar or another, because they must somehow rely on apparent 
>>> time, and not mean time, because the julian period count apparent 
>>> solar days.
>>>
>>>
>>> Let us use ISO 8601, and abolish leap seconds all together.
>>>
>>>
>>>
>>> _______________________________________________
>>> LEAPSECS mailing list
>>> LEAPSECS at leapsecond.com
>>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>>
>>
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20170111/c3232930/attachment-0001.html>