Dan ( also for Laurent and other OMs),
As y'all have seen and experienced when operating FTxx APPs (WSJTx and JTDX "direct" connection to Log4OM V2 AND running WSJTx via JTAlert) once a spot is selected in the FTxx APP it will appear in the Log4OM Main UI with a certain set of values the Log4OM V2 brings to the screen from it's internal databases.
In most cases we see certain ITU and CQ zone values in the Log4OM Main UI.
Then, once the QSO is completed and saved the data is then sent via UDP from the FTxx APP to the Log4OM V2 database (SQLITE or MYSQL) and saved in that file and finally visible in our Recent QSO's (F7) grid.
This is where we will often now see a difference in either the ITU or CQ zone (or both) for that QSO.
Terry and I have gone over my findings (yet again) this morning and the bottom line is that Log4OM V2 is merely taking the data (via UDP generally) from the FTxx APP and saving it to the database file. The assumption is that the FTxx APP has made certain choices to ID the ITU & CQ zone values to include with their data packet.
Terry shared this comment with me today: "if data comes from an external source it would be wrong for us to change it even if it's wrong because we must assume that is the data the user wants recorded "
Also ... if it is determined that certain data is continually wrong from the FTxx APP developer then the OM should reach out to them to make corrections in the data they provide with a completed QSO.
Hope this helps a tad.