KML TimeStamp date-month swap in non-POSIX locale


Building the new kml module in a non-POSIX locale fails because day and month are swapped in KML timestamps in a POSIX locale (which is what the broken KMLTest expects).

This passes:
LC_ALL=C mvn -o -Dtest=KMLTest test

Otherwise with non-US UTF-8 locale this fails:
mvn -o -Dtest=KMLTest test

Looks like Jenkins and Hudson helpfully set C/POSIX locale, hiding this failure.

Failure looks like this:

Failed tests: testTimeTemplate(org.geoserver.kml.KMLTest): expected:<2002-2T00:00:00Z>
testTimeInvervalTemplate(org.geoserver.kml.KMLTest): expected:<2002-

So the test is expecting "2002-02-12T00:00:00Z", but looking in reveals 2002-12-02; the month and date are swapped!!!

It looks like the problem is that FeatureTemplate forces US date format "MM/dd/yyyy", but PlacemarkTimeDecoratorFactory.PlacemarkTimeDecoratorFactory handles dates differently, so a date passed into a string and then re-encoded gets its day and month swapped. The result is <b>correct</b> in a non-POSIX locale, but KMLTest then fails because it expects the swapped values.




Brad Hards
September 26, 2016, 12:30 AM


Doing a bit of JIRA review in preparation for this week's bug fix frenzy.
Can be
closed, or do we need to refactor this test or the code?



Ben Caradoc-Davies
September 26, 2016, 2:54 AM


this is a live issue. I just confirmed that I still see the same two
test failures in a non-POSIX locale. The two tests are currently
@Ignored. This issue might be a suitable candidate for the sprint.

Andrea, you expressed concern that care was needed to not break KML time
templates for existing users.

Kind regards,

Ben Caradoc-Davies <>
Transient Software Limited <>
New Zealand

Geoserver-devel mailing list

Brad Hards
September 26, 2016, 9:30 AM

OK. Will dig a bit more. Can reproduce the problem, and it looks like a problem with the test rather than the code.

The output KML has "2/12/02 12:00 AM" in the placemark description, and

Andrea Aime
October 28, 2016, 5:39 PM

Meh, it's actually a bug... the code in FeatureWrapper turns all attributes in strings for the template to work on, using the default locale, and then the KML code tries many patterns to parse it, but does not try the same one used by FeatureWrapper first, parsing the date the wrong way.
Both the notion of dumping in freemarker a locale dependent string, and passing through a template when a time attribute is already available, seem wrong to me, but they have been like that forever so.... I've fixed the kml code to try first the FeatureWrapper date patterns...

Andrea Aime
February 15, 2017, 11:52 AM

Mass closing all resolved issues not modified in the last 4 weeks



Andrea Aime




Fix versions

Affects versions