Is there any thought to validating the data entered into certain fields? There are two common errors I see when processing logs received from HAMRS users. The first one is the TIME_ON entry. I have often seen the time shown with a semicolon instead of just the four digit time, e.g. 21;57. I believe where this comes from is when the contact entered after the fact and the user tries to change the time and inadvertently hits the semicolon instead of the colon. Less often, I see invalid times like 2752. If the program could either reject the time when the contact is saved or throw an error on export as invalid data, that would be good.
Another error I am frequently seeing is the QSO_DATE being in the future. Again, I assume this is from contacts being logged after the fact and the user simply fat-fingering the date. Another case where, during export, the fields could be validated and throw an error if the date is in the future, that would be helpful. Granted, I am not much of a programmer, but I don’t think the code required to scan the entries on export and apply a little logic to be sure the time is only four numbers between 0000 and 2359 (minutes not to exceed 59) and the date not to be beyond today’s Zulu date shouldn’t be that difficult.
Thanks for your time.
73,
Michael WA7SKG
POTA 7th Area Coordinator
@WA7SKG Michael, thanks for volunteering your time to process logs for POTA activators. That’s a busy job!
I believe @Jarrett built in some safeguards for the time format entry in the latest versions of HAMRS. In fact, I just tried to manually enter a time using a semicolon and HAMRS won’t accept it. I suspect these are edited afterwards using another editor (probably a text editor).
However, it will let me enter a time that is greater than 2400, which should as you indicated be deemed invalid. Recommend @Jarrett look into ways to restrict the manual time entry.
Are the future dates you are finding in the QSO_DATE field, or in the QSO_DATE_OFF field? There was a bug with the latter in prior releases of HAMRS, where the QSO_DATE_OFF would reflect the date the QSO was entered, instead of the actual QSO date. That bug was fixed in the current release (v1.0.1).
But at present HAMRS will allow entry of a future date so I agree that would be worth addressing, too.
For the logs where you are seeing these problems, what version of HAMRS was used? It should be visible in the ADIF header.