Martin, JM Steel, all sirs:
>There have also been proposals that "Unix time" beat slowly either all day or 
>for the last few hours on "leapsecond day"  to >have 86400 "modified seconds," 
>while "leap second day" has 86401 SI seconds.
Has any one read/gone through my BASE contribution: The Metric Second; 1973 
April; pp.152-57; Bureau of Indian Standards, New Delhi wherein I have shown 
'my calculations' on increasing the day duration by 57.3314 second every day - 
to result in what we are now debating. 
I had not realised at that time that Metric Day (instead of solar Day or 
sidereal day) shall cause rotation of SUNRISE time
from "Morning-to Noon-to Evening-to Night- and then to Morning again", which is 
not a fit case to eliminate 'leapseconds' in the day. A viable option can be 
correction to Mean Year of Gregorian Year to Mean Year =365+31/128 =365.2421875 
day 
i.e. correcting the Leap Day Rule, as at: 
http://www.brijvij.com/bb_deci-sec-nu-mtr.pdf
This Mean Year can also be achieved, using Leap Weeks: 7*(52+159/896) 
=365.2421875 days.
The difference {365.2425 - 365.2421875 =0.0003125 day i.e. ONE day in 3200 
years} can be made to align Mean Year for Julian/Gregorian years with the 
*corrected New Leap Day Rule*. Thus, UT & TAI can be corrected to get rid of 
'leapseconds'
and stretching the second is not the solution! 
Regards,
Brij Bhushan Vij 
Friday, 20110708H10:21(decimal)EST
Aa Nau Bhadra Kritvo Yantu Vishwatah -Rg Veda 
The Astronomical Poem (revised number of days in any month)
"30 days has July,September, 
April, June, November and December 
all the rest have 31 except February which has 29 
except on years divisible evenly by 4; 
except when YEAR divisible by 128 and 3200 -
as long as you remember that 
"October (meaning 8) is the 10th month; and 
December (meaning 10) is the 12th BUT has 30 days & ONE 
OUTSIDE of calendar-format"
Jan:31; Feb:29; Mar:31; Apr:30; May:31; Jun:30 
Jul:30; Aug:31; Sep:30; Oct:31; Nov:30; Dec:30 
(365th day of Year is World Day)
******As per Kali V-GRhymeCalendaar***** 
"Koi bhi cheshtha vayarth nahin hoti, purshaarth karne mein hai"
My Profile - http://www.brijvij.com/bbv_2col-vipBrief.pdf
Author had NO interaction with The World Calendar Association
except via Media & Organisations to who I contributed for A 
Possible World Calendar, since 1971. 
HOME PAGE: http://www.brijvij.com/ 
Contact via E-mail: [email protected] 
 



From: [email protected]
To: [email protected]
Subject: [USMA:50841] Re: Stretching the second
Date: Fri, 8 Jul 2011 14:27:08 +0100










That would be a disaster.  I have recently finished a contract where I had an 
insight into the comms used for financial dealings.  The clocks used by the 
banks, traders, financial exchanges etc are GPS synchronised and many users 
start getting very agitated when their messages take an additional 100 ms to be 
transmitted.  Using “Unix time” as described by John would not work. 
 




From: [email protected] [mailto:[email protected]] On Behalf Of 
John M. Steele
Sent: 08 July 2011 13:38
To: U.S. Metric Association
Subject: [USMA:50838] Re: Stretching the second
 


There have also been proposals that "Unix time" beat slowly either all day or 
for the last few hours on "leapsecond day"  to have 86400 "modified seconds," 
while "leap second day" has 86401 SI seconds.

 

I think what is required is recognition that UTC and civil time are not the 
end-all-be-all.  Keep TAI, and then maintain TAI offsets for UTC and any other 
civil times.  The rules may change but the possibility of leap seconds and 
daylight savings are predicted.  The systems need to be able to preprogram the 
occurence instance and handle them automatically.  The requirement needs to be 
in the specification and the supplier needs to demonstrate compliance.  Leap 
hours kick the can down the road 500 years, ensuring 499 years of 
non-compliance, followed by panic.

 




From: Martin Vlietstra <[email protected]>
To: U.S. Metric Association <[email protected]>
Sent: Fri, July 8, 2011 6:56:58 AM
Subject: [USMA:50837] Re: Stretching the second

There was also a proposal to abandon leap seconds and introduce leap hours 
instead.  This would effectively have kicked the issue into the long grass for 
800 years.
 
About fifteen years ago I worked on a police crime recording computer system.  
The civil servants from the police force specified that daylight saving should 
be effected by speeding up and slowing down the computer clock rather than a 
step change.  The problem was that the database system could not handle such a 
mechanism, the development was too far down the line to do the job properly, so 
in the end they stopped the computer system at the start and end of daylight 
saving and when the clocks went back, the computer system was off the air for 
an hour.
 




From: [email protected] [mailto:[email protected]] On Behalf Of 
John M. Steele
Sent: 08 July 2011 11:04
To: U.S. Metric Association
Subject: [USMA:50834] Re: Stretching the second
 


Those who forget deserve to repeat history, or something like that.  
"Second-stretching" was already tried from 1960 to 1972.  While one atomic 
clock kept TAI, another was "steered" to drift from it at a controlled rate to 
approximate UT2, and the "steering constant" was declared for six months or so 
at a time.  That still wasn't perfect, and they declared mini-leaps of 50 or 
100 ms.  A total of 10 leap seconds were added in this manner before the 
present scheme was launched in 1972.

 

That scheme was considered too complex and unwieldy and the present scheme was 
viewed as an improvement in 1972.  Anyone advocating a return to yesteryear 
should explain in detail while it will work better now. (it won't, enough said.)

 

The other scheme I've seen proposed is leap-minutes or leap-hours.  Those would 
obviously occur at about 1/60 or 1/3600 the random rate of leap seconds.  That 
greater infrequency would lead to systems being LESS well designed to 
accomodate them in my opinion.  IERS provides notification (Bulletin C) of the 
plan for a leap second with approximately 5 months advance notice of the actual 
leap second, which is always scheduled for the end of June or December.  While 
longer intervals would be prefereable to "second stretching," I am convinced 
that those who fail to plan their systems for leapseconds would forget to plan 
for leapminutes.

 

If earth rotation drifts further so that more than 1 leapsecond per year is 
required, the second choice is end of March and September, and third choice, 
the end of any month.  Any system that is based on accurate time should either 
keep TAI or recognize that a leap second can be declared with advanced notice 
at the end of every month and operate a mechanism of obtaining that advance 
notice.  

 

I would note that most "atomic clock" products which receive radio time signals 
from WWB correctly decode and implemnent the leapsecond, and that NIST makes 
the notification available in their Internet time protocol as well (with less 
advanced notice).  The GPS system keeps "GPS time" which is a fixed offset to 
TAI and broadcasts the differential leap second count in the navigational 
message.

 




From: James Frysinger <[email protected]>
To: U.S. Metric Association <[email protected]>
Sent: Thu, July 7, 2011 10:16:21 PM
Subject: [USMA:50831] Stretching the second

Folks,

You might find this article of some interest. It reports an effort made by some 
people to convince the ITU (formerly, International Telegraph Union) to change 
the way that UTC is calculated, probably by departing from the "atomic second" 
as they call it -- actually, the unit second as defined by the SI. At least 
that's my reading of the article. Since all "leap seconds" have been positive, 
I suppose that amounts to them wanting to stretch the second, so to speak. Keep 
in mind, these are radio and TV folks, not metrologists most likely.

My guess is that the ITU will listen politely and decline to take the 
recommended action.

Jim

http://www.foxnews.com/scitech/2011/07/07/scientists-fight-effort-to-redefine-time/?test=faces

-- James R. Frysinger
632 Stony Point Mountain Road
Doyle , TN 38559-3030

(C) 931.212.0267
(H) 931.657.3107
(F) 931.657.3108                                          

Reply via email to