Ever since the last leap second, the clock has sometimes shown time 2 seconds fast for a few minutes after a cold start. It's puzzling that this error is two seconds and that it's in the positive direction, but the explanation for it is that one of the bits of data you get from the satellites is the delta between GPS time (which was zero in 1980, so it's 19 seconds ahead of TAI - it has all the leap seconds that happened in the 70s, but none since) and UTC (the basis for all civil time today). UTC systematically drifts away from TAI with the application of leap seconds, of which there have been 27 so far (the actual TAI-UTC delta, however, is 36).

GPS transmits the message that contains the current GPS-UTC delta every 12 minutes. The GPS module firmware has a default value compiled in so that it can give "correct" time before this message is received, but in the interim between the first fix and the receipt of that message, the time will be corrected with the compiled-in default. If that default is wrong, then the time will be wrong.

The bad news is that there's no indication from the GPS module that this is taking place. The good news is that, assuming good reception, it should never last longer than 12 minutes, and it should always be an exact integral number of seconds of error.

While a firmware update to the GPS module could fix the problem, it wouldn't prevent the problem from happening again the next time there's a leap second.

For this reason, I've decided to add the footprint for a supercap to the boards. The GPS-UTC offset is stored along with the almanac and preserved across warm starts, so this will allow the clock to not have this issue as long as the power is not lost for more than around 3/4 of an hour or so. Alternately, instead of a supercap, you could add a primary cell, but if you do so, you *must* use a schottky diode in series to prevent the cell from being back-fed current while the clock is powered.