RBN Hole just squirted out a spot for WD6TED. We all arrived on his freq. to hear him having an SKCC QSO. I thought, OK that’s weird but it is a pretty slow SOTA day so he might as well spend some quality time on the QSOs =)
So I waited until he finished up with KA3LOC and then called him. Long pause. He calls me back and I give him the standard SOTA QSO treatment, knowing there are lots of other chasers waiting their turn. I sign off with him and I hear the pileup calling him… no response.
Thinking, hrrm something is not right here I go and look at SOTAWatch again… I see that his spot was posted by RBN Hole but I DO NOT see any alert for Today. I do see an alert for Monday 16 October 2919 =)
So, why did RBN Hole throw a spot? Is the code only looking at the last 2 digits (gasp!)? Isn’t that how we got in to the whole Y2K mess?
Sorry, did I mention it’s a slow SOTA day? Guess I should get back to work now…
It will be something where (typically) a US format date squeezed through an EU format date route produces a daft date. This daft date when retrieved produces a date that aliases with a real date causing a spot to be produced when it shouldn’t. i.e. 16-10-2919 under/overflows back to 17-12-2019
No, he’s been spotted by RBN a few times recently and not been spotted, so it’s something peculiar. All dates are stored as 64-bit Unix epochs, so it’s not a date format thing (I can see the dates are stored correctly). My next thought was a 32-bit wraparound, but that doesn’t compute.
As to where the mistake came from, it’s clearly a fat finger problem, although the comment on the alert might give a clue too