Nasty date bug

12 posts / 0 new
Last post
M0TRN
Nasty date bug

Hi,
Had a QSO that started on 13 Feb 23:43 and went on until 14 Feb 00:15.
When I was done I hit Enter to save the QSO to the log, and all seemed fine. But then I wanted to check some details from the QSO so I brought up the QSO list and it wasn't showing. So I thought it had been lost.
Then I searched for the call of the guy I was talking to and it came up but it had been saved with the wrong date: instead of 2013-02-13 it was saved as 2012-02-12, or a day before the QSO happened!
I wonder if this has happened to other QSO's in the past and I've just not noticed it. In any case a pretty serious bug and I hope it gets fixed!
This is CQRLog 1.5.2 running on Debian Wheezy.
73, Thomas

PA3GOS
Re: Nasty date bug

Seems to me the same bug was reported a few days ago by AA5KV in "Sort order". If I am still awake around that time I'll try to check if I get the same result. Running CQRLog 1.5.2.1 on Ubuntu 10.04.
If so, it's a nasty bug indeed. Both EQSL and LOTW will ignore the QSO too.
 
73 Tjalling PA3GOS.

PA3GOS
Re: Nasty date bug

Okay, I have tested it with a fake QSO. Which ofcourse I deleted afterwards.
Indeed, the QSO was logged on february 13 instead of february 14 which it should have been.
So it's a real bug. Maybe in CQRLog 1.5.2 (not.1 which I typed in my earlier post) or something in MySQL.
 
73, Tjalling PA3GOS.

ok2cqr
ok2cqr's picture
Re: Nasty date bug

Hello Tjalling,
 
CQRLOG saves QSO when it started, so I suppose, it's OK. It saves start and end time. If your QSO started on 13 of Feb at 23:59 and ended on 14 of Feb 00:01, it should be saved with date 13 FEB because it started on 13 of Feb.
 
73 Petr, OK2CQR

RU2FM
Most loggers for Windows

Most loggers for Windows saved QSO with END time ( also in the contest) and this good practice. 

73! Val  RO2F ex: RU2FM

PA3GOS
Re: Nasty date bug

Hello Petr,
 
Thanks for your reply. I know the starttime is the most important time and should be saved.
Thing here is: The (in my case test) QSO was made between february 14 23:53 UTC and february 15 0:12 UTC.
In such a case CQRLog strangely saves the QSO as being started on february 13. If I take a look at the list, both the QSO list as well as the list in the main logging window, the QSO is not on top resp. on bottom. It's in between previous QSO's because of the recorded date being one day earlier than the actual date.
 
73 Tjalling PA3GOS.

ok2cqr
ok2cqr's picture
Re: Nasty date bug

Hello Tjalling,
 
oh, I didn't know about that. It's finex in SVN. A few seconds a go, I commited the fix. New version will be released next week. Thanks!
 
73 Petr, OK2CQR

PA3GOS
Sorry Petr

I did not see your reply earlier. Thank you!

k8wdx
CQRlog is taking the date

CQRlog is taking the date from the start time not the end time, this is the problem, just tested it myself, same thing here, CQRlog should be taking the date from the end time not the start time to avoid this issue, Yes the start time is important but everyone logs the end time not the start time, this is why when you start the qso before UTC and end after UTC the qso will be logged 24 hours before the atual log time.....Tom K8WDX

Tom K8WDX

PA3GOS
Re: Nasty date bug

Hi Tom,

 

You are helping a whole lot of people on these forums. Much appreciated.

Nevertheless, this time you are not right. Most, if not all, logging programs record the starttime of a QSO. This is also mandatory if a longlasting QSO should be confirmed through EQSL and/or LOTW.

Please read my previous post again. CQRlog skips a whole day back when logging a QSO that occupies two dates.

So a QSO lasting from 23:55 on, say, february 18 to 0:05 on february 19 will be saved as started on february 17 23:55. That is a bug in either CQRlog or MySQL.

This bug was reported by two HAM's and me. Ofcourse, I only tested it with a fake QSO around midnight UTC yesterday. Still, I have comfirmed that it really happens.

 

Tom, thanks for reading and I am convinced that Petr will solve this.

 

73 Tjalling PA3GOS.

k8wdx
Tjalling

Tjalling
 
 Thanks for your input, I am no expert when it come to computers, I do manage to work things out though, but I have noticed this problem myself, and have had to change the date on the logged qso for the same reason, of coures UTC time here is at prime time, 7pm now and 8pm after the time change, I just figured that that was the problem, not really sure but there is definaltly an issue, when I logged a qso that started at say Feb 16th at 11:57 and ended Feb 17th at 00:02 the qso would show up in the log at Feb 16th at 00:02, so I only asumed that CQR log was using the start date to determine what the date was, when it should be using the end date. Again just a guess on my part. I will leave this up to the expert, hi hi.. this has hapend to me several times, it is not often that the qso starts and ends in this perfect window of time if you know what I mean.  reguards Tom K8WDX

Tom K8WDX

PA3GOS
Okay Tom and thanks Petr

Well, midnight UTC is 01:00 or 02:00 local time here... So I don't have many QSO's with that issue. So to test it I made a fake one. From what I've seen, in your example, the date would be saved as Feb. 15. That is the weird thing.

 

If the logged date would match any of the two dates the QSO was actually on it would be less complicated.

 

Oh, now I see Petr has already responded and fixed it. Thank you very much Petr for all the effort you put in our favorite logger!

 

73, Tjalling PA3GOS.