In reply to MM0FMF:
So there you go, broken? I don’t think so.
What is broken is that the requirements contradict the documentation.
When this question comes up (and it has come up before), there’s this slightly reluctant revelation that the date in QSO records is expected to be the date that the activation started. That is slightly surprising, but we live in an imperfect world and if that is the spec so be it.
But what if somebody does read the spec? It’s in:
http://www.sotadata.org.uk/ActivatorCSVInfo.htm
This states, quite clearly, no ambiguity, that the “date” column of CSV or TSV records should contain “The date of the QSO.” Don’t take my word for it - go read it. There’s no mention of having to fudge it if an activation crosses a UTC date boundary.
There’s been a big change since 2002. Back then, SOTA was UK-centric. Activations crossing midnight were rare, and when they did happen, would be made by “serious” activators likely to get many QSOs before and after midnight. This “edge case” wasn’t really a problem.
Ten years on, SOTA spans the planet. Activations crossing the UTC day boundary happen in daylight hours and may be expected to become commonplace. They may also be activations that get relatively few contacts. The “two before and two after” scenario which triggered this latest discussion is not at all unlikely. If such an activation is submitted using a CSV file in accordance with the published specification, it will not score. I’d say that was broken.
I venture to suggest that circumstances in which you would actually want a sequence of QSOs crossing a date boundary to count as two separate activations are much rarer. It only affects the score if it crosses a YEAR boundary. Only a small handful of people care about the number of activations of a summit recorded against their names.
My view, for what it’s worth, is that the code should favour the common case of ordinary people doing ordinary activations, at the possible cost of requiring people with special requirements to do something odd. It seems to me that simply changing the CSV upload code so that it does not start a new activation if the date increments by 1 would achieve precisely that. It would have the added advantage that the written specification would be correct.
I can’t see that it would break anything except the obscure case of people wanting to record separate activations of the same summit on consecutive days. These people could simply be advised to upload the two activations separately.
You’re right that this doesn’t affect me personally. And yes, I’m looking at it from a programmer’s perspective, a world in which edge cases are what it’s all about. And no, I can’t put the effort into providing a suggested fix because you’re running a “closed source” system. But your helpful description of the CSV upload process suggests to me that this issue is really rather simple to fix.