In message: <[email protected]> Mark Calabretta <[email protected]> writes: : : On Sun 2009/10/04 12:49:06 +0200, Magnus Danielson wrote : : >Of course it cannot output a correct UTC solution until it has received : >page 18 subframe 4, but it can store the leapsecond offset in : >non-volatile RAM since last lock and for most of times that would give : >correct UTC from first lock. How many if any receiver uses that, I do : >not know, but it is technically possible, just as you store the almenac : >data and last known position in order to accelerate those first 12,5 : >min. Recall, for this strategy to fail, the receiver must have been : >turned off over a leap-second event. Most times it is turned off is not : >a leap-second event. : : Given that leap seconds are announced six months in advance, how : difficult would it be for GPS to disseminate that information : and for receivers to store and use it?
They already do that. However, it turns out there are a number of edge-case ambiguities that make for interesting problems that have been talked about here... The fundamental problem is that leap seconds are announced 6 months in advance. This is too little time. Warner _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
