[LEAPSECS] Crunching Bulletin B numbers (POSIX time)
Richard B. Langley
lang at unb.ca
Thu Feb 24 07:26:58 EST 2011
Quoting Warner Losh <imp at bsdimp.com>:
> On 02/23/2011 05:57, Richard B. Langley wrote:
>> For those who might not be aware. Loran-C in North America is dead.
>> It might be resurrected as eLoran or some other LF service in the
>> future:
>> http://www.ursanav.com/sites/default/themes/danland/images/buzz/pdfs/LF-Solutions-for-APNT-ION2011.pdf
>
> Well, eLoran was implemented in the North American chain a couple of
> years before they started to shut it off. Given that the stations
> have been decommissioned and the towers blown up in at least some
> places, I doubt it will ever resurrect.
The decision to terminate Loran-C in North America, leaving GPS
without an effective backup there, was extensively covered in GPS
World. eLoran was initiated but not completed. I had an article in my
column about GPS plus eLoran before Loran-C got the chop:
<http://www.gpsworld.com/transportation/road/innovation-gps-loran-c-6550>.
-- Richard
> But the requirements of that system, and how they interacted with
> other requirements when coupled with inflexible military bureaucracy
> shows that there's a wide diversity of requirements for some problem
> domains that you don't run into with a server in a computing center.
>
> Warner
>
>>
>> -- Richard
>>
>> Quoting Ian Batten <igb at batten.eu.org>:
>>
>>>>
>>>> Nope. tried that when getting the spec approved. Approximate
>>>> times weren't allowed. UTC times were required. There was no
>>>> way to indicate approximate time in the user interfaces present
>>>> (how do you blink a 5071A anyway :). The other systems that
>>>> interfaced to ours had a fixed format, and required UTC and not
>>>> approximate UTC for a while and then a possible jump in time to
>>>> actual UTC.
>>>
>>> Well, if the use-case is navigation (Loran, military) then UTC
>>> sans leap seconds isn't much use to you anyway, so the "solution"
>>> of dropping them would take your requirement with it, and you'd
>>> seen something closer to UT1. And of course, requirements are
>>> simply line items on an invoice, and if deriving immediate UTC
>>> costs 10X rather than X, the customer has to make a decision on
>>> whether they're prepared to pay for it. Just saying "my customer
>>> demands X and therefore the rest of you need to enable X" isn't
>>> realistic.
>>>
>>> ian
>>>
>>> _______________________________________________
>>> LEAPSECS mailing list
>>> LEAPSECS at leapsecond.com
>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>>>
>>
>>
>>
>> ----------------------------------------------------------------------------- | Richard B. Langley E-mail: lang at unb.ca
>> |
>> | Geodetic Research Laboratory Web:
>> http://www.unb.ca/GGE/ |
>> | Dept. of Geodesy and Geomatics Engineering Phone: +1 506
>> 453-5142 |
>> | University of New Brunswick Fax: +1 506
>> 453-4943 |
>> | Fredericton, N.B., Canada E3B 5A3
>> |
>> | Fredericton? Where's that? See:
>> http://www.fredericton.ca/ |
>> -----------------------------------------------------------------------------
>> _______________________________________________
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
>> http://six.pairlist.net/mailman/listinfo/leapsecs
>>
>>
>>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
>
-----------------------------------------------------------------------------
| Richard B. Langley E-mail: lang at unb.ca |
| Geodetic Research Laboratory Web: http://www.unb.ca/GGE/ |
| Dept. of Geodesy and Geomatics Engineering Phone: +1 506 453-5142 |
| University of New Brunswick Fax: +1 506 453-4943 |
| Fredericton, N.B., Canada E3B 5A3 |
| Fredericton? Where's that? See: http://www.fredericton.ca/ |
-----------------------------------------------------------------------------
More information about the LEAPSECS
mailing list