Date is parsed with the incorrect year and stored in the STP_HEADER table.
Mon, 13 Sep 171700 17:51:47 1303 Mon Sep 13 17:30:04 UTC 171700
I don't know what is causing this one. There is some sort of bug in the way that the date is processed from the STP record. I have two STP files from Alan for that record:
The header for the first one is:
Sequence: 312478
Source: amsat.fox-1d.ihu.duv
Length: 768
Date: Sun, 13 Sep 2020 17:51:47 UTC
Receiver: WA4SCA
Rx-Location: N 35.9375 W 86.708336 270
Frequency: 145879170 Hz
Receiver-RF: Airspy R2 with SDR#
Demodulator: FoxTelem 1.08z5 - 3 Mar 2020 (windows 10)
and the second one is:
Sequence: 299943
Source: amsat.fox-1d.ihu.duv
Length: 768
Date: Sun, 13 Sep 2020 17:51:47 UTC
Receiver: WA4SCA
Rx-Location: N 35.9375 W 86.708336 270
Frequency: 145880150 Hz
Receiver-RF: FCDP+
Demodulator: FoxTelem 1.08z5 - 3 Mar 2020 (windows 10)
So nothing seems off. The bug must be in the way that I parse the date in the server or the way that the mySQL server saves it to the DB.
There are no errors in the server log. Both records are processed normally:
20200913175147: -/206.251.209.178 Processed: 245 bytes from WA4SCA for 4 130 1303 3---2020/09/13/20200913175147.563.stp
20200913175147: -/206.251.209.178 Processed: 231 bytes from WA4SCA for 4 130 1303 3---2020/09/13/20200913175147.565.stp
So I guess I need to put the two STP records into my test environment and try parsing them. Note that the STP file is text. So I parse the date into Java. Then I store it in the DB. But I really fail to see why it would fail...
Date is parsed with the incorrect year and stored in the STP_HEADER table. Mon, 13 Sep 171700 17:51:47 1303 Mon Sep 13 17:30:04 UTC 171700
I don't know what is causing this one. There is some sort of bug in the way that the date is processed from the STP record. I have two STP files from Alan for that record:
grep "17:51:47" *.processed gives: Binary file 20200913175147.563.stp.processed matches Binary file 20200913175147.565.stp.processed matches
The header for the first one is: Sequence: 312478 Source: amsat.fox-1d.ihu.duv Length: 768 Date: Sun, 13 Sep 2020 17:51:47 UTC Receiver: WA4SCA Rx-Location: N 35.9375 W 86.708336 270 Frequency: 145879170 Hz Receiver-RF: Airspy R2 with SDR# Demodulator: FoxTelem 1.08z5 - 3 Mar 2020 (windows 10)
and the second one is: Sequence: 299943 Source: amsat.fox-1d.ihu.duv Length: 768 Date: Sun, 13 Sep 2020 17:51:47 UTC Receiver: WA4SCA Rx-Location: N 35.9375 W 86.708336 270 Frequency: 145880150 Hz Receiver-RF: FCDP+ Demodulator: FoxTelem 1.08z5 - 3 Mar 2020 (windows 10)
So nothing seems off. The bug must be in the way that I parse the date in the server or the way that the mySQL server saves it to the DB.
There are no errors in the server log. Both records are processed normally: 20200913175147: -/206.251.209.178 Processed: 245 bytes from WA4SCA for 4 130 1303 3---2020/09/13/20200913175147.563.stp 20200913175147: -/206.251.209.178 Processed: 231 bytes from WA4SCA for 4 130 1303 3---2020/09/13/20200913175147.565.stp
So I guess I need to put the two STP records into my test environment and try parsing them. Note that the STP file is text. So I parse the date into Java. Then I store it in the DB. But I really fail to see why it would fail...