[LEAPSECS] alternative to smearing

Robert Jones robert at jones0086.freeserve.co.uk
Wed Jan 11 18:18:00 EST 2017


slight revision


On 11/01/2017 23:16, Robert Jones wrote:
>
> I should add that as the universe is now considered to be expanding at 
> an accelerated rate, that should have some interesting relativistic 
> effects on time and its measurement in the long term
>
>
> On 11/01/2017 23:04, Robert Jones wrote:
>>
>> 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/d1d925f5/attachment-0001.html>


More information about the LEAPSECS mailing list