In my view there is a good argument for
A. recording in the database exactly what the activator uploaded.
B. Then, after ingesting the data, the software managing the database (I still don’t like calling a website a database) would:
- assign activation IDs to group the contacts that the rules say should be grouped together (with stated criteria)
- allocate the points if any and
- determine any bonus points if any.
The advantage of this is that contacts can be compared more readily between activators and chasers - yes, no requirement for that, but keeping data pure is a good goal in itself. Also, downloaded data can be used to re-load without manual changes to lots of dates.
The first dot point is very difficult to define other than saying all contacts in a sequence for the same activated summit reference are a single activation (the current situation). An alternative would be to define a time gap after which the remaining contacts would be deemed a new activation. In that case the 3 contacts before 2359 still get nil points, but 4 or more after 0100/0200(whatever) constitute a new activation and are eligible to be assessed for points and bonuses. Other than 31 Ded/ 1 Jan, they would not get more points, but at bonus rolllover, the second “activation” would qualify for bonus points. Problem, if the second activation won’t be recognised with the entire log submitted, two partial logs may be submitted to force the system to yield the points. Contrary to intentions, so not a good idea.
The more consistent approach is I think to apply the rules for activations as they are today, but let people know they have to have enough contacts on the new (bonus qualifying) day, for it to be considered for the bonus points. That avoids all confusion about how bonus points are earned - ie. sufficient contacts need to be on the actual utc date that meets the bonus conditions of the ARM.
If I operate at Mt Ginini for an entire VHF field day weekend with my sota station electrically isolated from my vhf gear (which is typically generator powered), I could make contacts on Friday evening, Saturday morning and all day, Sunday morning and up to lunch time. UTC timings would be 0700, 2300, 0400 next day, 0900, 2300, 0400 on third day. If submitted as a single log, the assigned date will be Friday for the whole weekend. This strikes me as an unintended consequence too. i receive queries from operators all over as to why I logged them with the wrong date, when I actually didn’t.
I dare say the original rules didn’t attempt to cater for these problems when the only associations were in the UK or nearby. But they emerge once wide variations of time zones create new glitches. Andrew ZL3CC gave more good examples.
In such cases my analytical cell suggests returning to basics and examining what is intended, what is fair, and what is practical.