While testing the output of the new "processing date" in the headers of output formats that have them, I realized that the dates were not being output consistently between the different formats and even between different fields in the same formats.
While fixing this, I also updated the all of the date handling code to use the new Java 8 standard date and time classes. All of the dates we are using are just dates, with no time included, except for the searchTimestamp, which includes both date and time.
All of the Dates are now output consistently as "yyyy-MM-dd" (which is what was intended and was already happening in the most visible places), and the DateTime timestamp is output as "yyyy-MM-dd HH:mm:ss" (again as it was doing in the most visible place already). We are no longer outputting the name of the day of the week, the milliseconds, or the timezone, as was happening in some places in the code due to sloppy date output handling which was put in place over 7 years ago.
All date outputs were strings except for in the shapefile DBFs (whose output is unchanged) because the formats do not have any specific date types. I doubt anyone was trying to parse these dates, and even if they were, they should be more easily parse-able now than before.
While testing the output of the new "processing date" in the headers of output formats that have them, I realized that the dates were not being output consistently between the different formats and even between different fields in the same formats.
While fixing this, I also updated the all of the date handling code to use the new Java 8 standard date and time classes. All of the dates we are using are just dates, with no time included, except for the searchTimestamp, which includes both date and time.
All of the Dates are now output consistently as "yyyy-MM-dd" (which is what was intended and was already happening in the most visible places), and the DateTime timestamp is output as "yyyy-MM-dd HH:mm:ss" (again as it was doing in the most visible place already). We are no longer outputting the name of the day of the week, the milliseconds, or the timezone, as was happening in some places in the code due to sloppy date output handling which was put in place over 7 years ago.
All date outputs were strings except for in the shapefile DBFs (whose output is unchanged) because the formats do not have any specific date types. I doubt anyone was trying to parse these dates, and even if they were, they should be more easily parse-able now than before.