Thanks Jim.  This Zones thing is driving me crazy.  Not sure where data is coming from.  Just finished QSO with N3BNA.  All agree Grid is FN10uf.  Log4OMv2 has location as ITU/CQ as 8/5, and so does JTAlert as 8/5, but logged QSO is 6/0.  All captured on attached pic.  Will post over on Log4OM forum as well.   73 Herb WB8ASI

On May 9, 2020 at 7:56 PM Jim N6VH <N6VH@...> wrote:

On 5/9/2020 2:35 PM, WB8ASI Herb wrote:

I've started seeing CQ zone=0.  In my pursuit of accurate data I find many misloggings of ITU and CQ zones based on a good Gridsquare.  I know there is confusion when some one is operating from a different gridsquare from their licensed location on QRZ.  I have 2 locations and try and make sure I QSO and QSL appropriately.  However, something is off normal in lookups.   There is an active discussion on the Log4OMv2 Forum on the CQ zone=0 thread.  In my log review and cleanup attempt, I found one that seems to have a JTAlert twist.  Looking up an old QSO with WQ6X.  All appears that he is on Alameda Is in CA grid CM87US on QRZ, V2 Main UI, and JTAlert all agree. Zone-Check.eu shows that it should be ITU 6, CQ 3.  The Main V2 UI shows such and logs properly this time as 6 3.  JTAlert shows ITU 6, CQ 5.  That is not possible.  Where does the 5 come from???.   If I update the QSO in my V2 log it changes to from correct CQ 3 to CQ 5, so I will not save.  I'm not a big Zone watcher, thus not a big issue for me, but would rather have blank info rather than bad info.  This Zone Problem is not at all JTAlert, but it is in this example.  Something in the lookups is not right.  I will try and determine when it started as I continue to check in my extra COVID19 time, and let you know.  I thought it started with V2, but the above example is dated July 2019.  I'm not losing sleep over it.  Don't anyone else either.  73 Herb WB8ASI