I converted a new batch of SOTA contacts from an ADIF to CSV using the converter on the SOTA Mapping page. The conversion was good so I saved it and uploaded it to my SOTA log just to find out the the dates were changed when saved. As an example the date displayed in the converted log showed day/month/year. When saved it changed to Month/day/year. The uploaded log save as the wrong dates, Aug. 2 got changed to Feb. 8, as an example. I had to search them all out and delete them. I hope I got them all. When I opened it in the SOTA CSV Log Editor the dates show correct. I saved it again from the SOTA CSV Log Editor. When I tried up upload it again the dates were changed to month/day/year again. How can I keep the dates correct? The last two uploads I did worked but I guess that was because the days uploaded were greater than 12 so it was able to do it correctly. Is there a way to upload the log to my SOTA log directly from the SOTAMAPS-EXTRA converter or the SOTA CSV Log Editor to avoid this problem?
Jeff K6QCB
Very strange as both formats have a fixed arrangement of year month day.
ADIF: Released ADIF Version 3.1.0, updated 2019/05/21
YYYYMMDD format, where
* YYYY is a 4-[Digit](http://www.adif.org.uk/310/ADIF_310.htm#Digit) year specifier, where 1930 <= YYYY
* MM is a 2-[Digit](http://www.adif.org.uk/310/ADIF_310.htm#Digit) month specifier, where 1 <= MM <= 12 [use leading zeroes]
* DD is a 2-[Digit](http://www.adif.org.uk/310/ADIF_310.htm#Digit) day specifier, where 1 <= DD <= DaysInMonth(MM) [use leading zeroes]
SOTA CSV:
https://newsotadata.sota.org.uk/en/upload/activator/csv/info
The date of the QSO. Most date formats are accepted but be careful about USA vs. International date format. Use of International date format (DD/MM/YY) is recommended.
The question is were the mistake happens.
Compare in editor like Notepad or Notepad++
Btw. did you upload to sotadata.org.uk or to the newsotadata.sota.org.uk ?
The second should have a better file-parser (reader).
73 Joe
Beware of helpful software that reads dates and then displays them in the locale rather than what was in the file. It should save it back in the same format as it read it no matter how it was displayed. But there are some packages that have a mind of their own. Excel, I’m thinking of you, especially as Excel can be somewhat random as to whether it plays nice with the data or not.
Try to convert your ADIF file to CSV with this online resource.
I tried both the sotadata and the newsotadata pages same problem with both. I tried the Adventure Radio converter same problem. Then I had a thought and I changed the date setting in DXKeeper to give the month in word format instead of a number. That fixed the problem. Apparently it can determine the date correctly if the month is in English instead of a number, regardless of what order they are in.
Thanks for the help.
Jeff K6QCB
You have a program somewhere in the chain of software you are using that is using the locale for your computer and that plays with the dates. Can you name every piece of software you are using to read and process the files and we can help you find which one is breaking the format? Oh and which OS are you using?
I am using Windows 7 pro. I export an ADIF from DXKeeper. I upload that file into the converter on the Mapping page extras tab. I then click on the save as CSV button. The box comes up asking to save or open. I open in Excel and save it. I also did it again but this time opened it in wordpad and saved it. Same result. When opened in word pad or the SOTA CSV Log editor the dates are day/month/year. In excel they are Month/Day /Year. After opening it in SOTA CSV log editor with the dates showing correct I saved as then tried to upload it again and same result, dates were wrong. I changed the default program to open CSV files to wordpad but had the same result. Changing th date format to a word for month in DXKeeper fixed it. But funny thing the last time I did it as described above it worked. Most of the dates were with a day greater than 12, but the last day uploaded was 8/1/2019 (Aug 1). For some reason that day worked correctly it did not get converted to Jan. 8, 2019, like what happened this second time that prompted this topic.
Jeff K6QCB
There’s your problem. Excel is using your en-US locale to munge the dates into US format. Remove Excel from the tool chain and just save it.
I did that I set Notepad as default program and saved it from Notepad, no excel, and had the same problem.
I made a mistake in the previous post I meant Notepad not Wordpad.
Jeff K6QCB
These two don’t agree with each other. Anyway, as per the last time, send me the CSV file. It’s clearly a locale issue
and the ADIF file too, please.
Just to finalise this one, once Jeff changed the date format in DXKeeper, the ADIF file was created properly. The date generated was not valid by ADIF standard.
In other news, since I’m such a nice guy, there’s a new feature in newsotadata, let’s see how long it takes for the first bug report to show people have found it 
I need to activate again to try the new feature - maybe tomorrow. 
Couldn’t wait to try it out.
Deleted an old activation and reloaded the ‘new’ way- worked OK
Hello,
I have a problem with upload an ADIF log.
The date is one month early!
as example a one line log whose date is 27/08/2019
<STATION_CALLSIGN:7>F6HBI/P <QSO_DATE:8>20190827 <TIME_ON:4>1603 < CALL:5 >F5LKW <MY_SOTA_REF:8>F/AM-787
When uploaded the activation date is 27/07/2019
see the download csv:
F6HBI/P,27/07/2019,16:03,F/AM-787,7MHz,SSB,F5LKW,
Is it my ADIF that is wrong?
Gerald F6HBI
Your ADIF looks fine.
I uploaded ADIF a couple of days ago and, now when I download I see the same problem. Activation was 30 June 2019, download log shows 30 May 2019.
Also shows wrong date on Activator log page.
@VK3ARR is keen to know the bugs so I guess that’s one of them.
“Must remember that JavaScript dates start their months at 0, not 1”
keeps coding
“Must remember that JavaScript dates start their months at 0, not 1”
keeps coding
forgets JavaScript dates start their months at 0, not 1
pushes code live
Reminds me of HP Basic on the HP85 in 1981 at university where there was an ‘OPTION BASE 0’ or ‘OPTION BASE 1’ to specify whether array indexing started at 0 or 1. Gosh that was a long time ago and I’m trying to think which lab we used them in, I think we used it to design LC filters which were then made up and measured. Just don’t have the powers of recall for complete trivia anymore. I do remember the queue waiting for turns on the single HP85 in the lab.