[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