[LEAPSECS] alternative to smearing

[Robert Jones]

I should add that as the universe is now considered to be expanding, 
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/f9344ed2/attachment.html>