4 ms·

The moral is we get to hear your cool war story. Thanks for sharing! ...okay yeah that's not a moral, but still.

imglorp 4y ago
Great, here's another. $work had thousands of full custom, dsp-heavy, location measurement hardware devices widely deployed in the field for UTDOA locating cell phones. It used GPS for time reference -- if you know your location, you can get GPS time accurate around the 10's of nanoseconds. GPS also broadcasts a periodic almanac which includes leap second offsets: if you wanted to apply the offset to GPS you could derive UTC. Anyway there were three models of these units, each with an off-the-shelf GPS chip from one of three location vendors you've probably heard of. The chip firmware was responsible for handling leaps. One day, a leap second arrived from the heavens. We learned the three vendors all exhibited different behaviors! Some chips handled the leap fine. Some ignored it. Some just crashed, chip offline, no bueno, adios. And some went into a state that gave wildly wrong answers. After a flurry of log pulling, debugging, console cabling, and truck rolls, we had a procedure to identify units in bad states and reset them without too many getting bricked. It seems the less likely an event is to occur, the less likely your vendor put work into handling it.
- CamperBob2 4y ago
  It seems the less likely an event is to occur, the less likely your vendor put work into handling it. This recalls perhaps the biggest mistake in the GPS specification, the 1024-week rollover period. A timespan long enough to be impractical to test without expensive simulator hardware, short enough to be virtually guaranteed to cause problems in long-term installations... and long enough for OEMs to ignore with impunity. ("Eh, it's 20 years, by that time I'll be retired/dead/working somewhere else.") Moral: timescale rollovers need to be designed to happen very frequently -- as in a few days at most -- or not at all. Unfortunately the leap second implementers didn't have that option.
  - dtgriscom 4y ago
    ... what if we switched to leap milliseconds?
  - m3047 4y ago
    Somebody on LinkedIn working in data science opined that they should do away with DST. I commented that yeah maybe they ought to, and then bring it back in 5 years, rinse / lather / repeat as a stress test. Got a number of likes.

Great, here's another. $work had thousands of full custom, dsp-heavy, location measurement hardware devices widely deployed in the field for UTDOA locating cell phones. It used GPS for time reference -- if you know your location, you can get GPS time accurate around the 10's of nanoseconds. GPS also broadcasts a periodic almanac which includes leap second offsets: if you wanted to apply the offset to GPS you could derive UTC. Anyway there were three models of these units, each with an off-the-shelf GPS chip from one of three location vendors you've probably heard of. The chip firmware was responsible for handling leaps. One day, a leap second arrived from the heavens. We learned the three vendors all exhibited different behaviors! Some chips handled the leap fine. Some ignored it. Some just crashed, chip offline, no bueno, adios. And some went into a state that gave wildly wrong answers. After a flurry of log pulling, debugging, console cabling, and truck rolls, we had a procedure to identify units in bad states and reset them without too many getting bricked. It seems the less likely an event is to occur, the less likely your vendor put work into handling it.

CamperBob2 4y ago
It seems the less likely an event is to occur, the less likely your vendor put work into handling it. This recalls perhaps the biggest mistake in the GPS specification, the 1024-week rollover period. A timespan long enough to be impractical to test without expensive simulator hardware, short enough to be virtually guaranteed to cause problems in long-term installations... and long enough for OEMs to ignore with impunity. ("Eh, it's 20 years, by that time I'll be retired/dead/working somewhere else.") Moral: timescale rollovers need to be designed to happen very frequently -- as in a few days at most -- or not at all. Unfortunately the leap second implementers didn't have that option.
- dtgriscom 4y ago
  ... what if we switched to leap milliseconds?
- m3047 4y ago
  Somebody on LinkedIn working in data science opined that they should do away with DST. I commented that yeah maybe they ought to, and then bring it back in 5 years, rinse / lather / repeat as a stress test. Got a number of likes.