Myself and a colleague download data from the same server.
We both do this using a command line script which calls Briefcase (so our call to Briefcase and all settings are identical). We both have the same date and time settings on our devices which are both macs.
But my dates (for example a TODAY field) come out as DD-MMM-YYYY and his come out DD MMM YYYY
This is then problematic for pre-scripted analyses we are both running.
Not sure if this is because the data is not stored as an ISO date field, if there is a way of specifying the format for dates at export etc but resolving this would be valuable
Hi @dr_michaelmarks!
Briefcase doesn't store any data (it just reads the XML form submissions) and, therefore, it depends on its source.
While exporting submissions to CSV, though, it reads date/time data and it generates a string representation using Java's MEDIUM style pattern which depends on the system's Locale settings. Taking this into account, what you describe is what can be expected: if two computers have different locale settings, Briefcase will probably produce different date/time strings.
I personally think that Briefcase should export date/time fields to ISO8601 format, which doesn't depend on the system's locale. The ISO8601 format is a standard and it's supported by most of the spreadsheets apps, analytics software, and databases. Would that work in your case?
2 Likes
-
I agree an ISO export of dates would be helpful
-
BUT the issue is a bit weirder than that
- We are both running our machines in the UK
- Same operating system
- Same clock settings (i.e if we click the Date/Time trop right on mac screen they both display the date as DD MMM YYYY
- Same advanced Date/Time display settings in preferences
So it is not clear to me that we have different locale settings (and if we do it must be hidden away somewhere)
Note that dates are both DD MMM YYYY just that one machine is adding hyphens to the CSVs
Wow, that's weird!
I'm going to ask an obvious question (sorry!): did you check the outputs it in a plain text editor? If you used apps like Excel you might be seeing differences due to user customized preferences...
1 Like
@dr_michaelmarks, one test to completely rule out different locales as the source of your issue is to run Briefcase with some JVM args to force a specific locale settings like this:
java -Duser.country=GB -Duser.language=en -jar briefcase.jar
This will force the en_GB locale on the running Java program.
Then, compare the outputs using a plain text editor.
(I originally posted this on the wrong post, sorry about that!)
Interesting we will try this.
Is there a list of locales anywhere?
1 Like
Sure!
Country codes are defined in the ISO 3166-2 standard and language codes use the ISO 639-1 standard.
Locales are often represented by a string combining the language code and the country code like this: en_GB
1 Like
Sadly this did not fix it
We now run a scripted call to briefcase (its shared script so we are running the exact identical file)
We include a specific setting to make locale = GB
my dates in text editor still appear DD-MMM-YYYY, colleagues DD MMM YYYY
Hi, @dr_michaelmarks!
This is another level of weird 
I guess the answer is "yes" but, I forgot to ask another obvious question: are you both exporting the same form?
Also, could you run the command java -version in both machines and copy here the output, please?
We can check the Java version.
Its a scripted call to briefcase which pulls the same set of forms on both computers.
1 Like
Thanks! I'm interested especially in knowing if you're both running Oracle/OpenJDK or any other vendor's JVM.
I've prepared a Java class that tests different ways of formatting dates related to how Briefcase does it. It would let me know if the Java environments are different. Could you run it on both computers and copy here the results as well, please?
DateTest.zip (1004 Bytes)
You need to unzip it and launch it with java DateTest. In my computer I get this output:
Date (no args) : Jun 20, 2018
Date DEFAULT style : Jun 20, 2018
Date MEDIUM style : Jun 20, 2018
Date DEFAULT en_GB : Jun 20, 2018
Date MEDIUM en_GB : Jun 20, 2018
LocalDate MEDIUM : Jun 20, 2018
Ok well this has definitely flagged a difference!
COMPUTER 1:
COMPUTER 2:
I then completely removed Java on computer 1 and installed JDK 10.01 - Hyphens gone, problem fixed.
But more broadly and from an ODK Feature perspective we need a solution whereby all dates come out in ISO format as mentioned above to avoid this kind of issue - real barrier to pre-scripted analysis
3 Likes
