getFeatureInfo, Freemarker template DateTimeFormatter problem since JDK 20

GeoServer GeoServer User
1

I investigated a problem using Geoserver integrated Freemarker Templates with Eclipse Adoptium: 21.0.8 (OpenJDK 64-Bit Server VM)

in my freemarker Template I had

<#setting locale=“en_US”>
<#setting boolean_format=“0,1”>
<#setting date_format=“dd.MM.yyyy”>
<#setting datetime_format=“dd.MM.yyyy HH:mm”>
<#setting time_zone=“Europe/Berlin”>

and

Datum Uhrzeit: <#if feature.datum.value != ''> ${feature.datum.value?datetime("MMM dd, yyyy, h:mm:ss a")} Uhr <#else> keine Angabe

This gave “Unparseable date: "Mar 30, 2024, 1:12:27 PM"” on getFeatureInfo request.

Solution: copy the unparseable date into your freemarker template text editor and use the “Narrow No-Break Space” between h:mm:ss and a.

see: https://bugs.openjdk.org/browse/JDK-8324308

ADDITIONAL SYSTEM INFORMATION :
Occurs in JDK 20, 21 and 22, but not in older ones like JDK 18 and 19.

A DESCRIPTION OF THE PROBLEM :
The US DateTimeFormatter uses a “Narrow No-Break Space” since JDK 20. This special character is used instead of a normal space before “AM” and “PM”. Especially for parsing a users input that is an serious problem, because users can not type this character on a normal keyboard. They also could not see the difference, so an error message with an example of an correct formatted DateTime could not help.

REGRESSION : Last worked in version 19

2

Hi Stefan,

this is quite annoying indeed, but I don’t see how GeoServer can do anything about it, the issue originates not even in the JDK, but seems to be in a library upstream of it.

We can only hope it gets handled, in the meantime, two suggestions, one more immediate, one a bit more disruptive.

The immediate bit is a workaround, have you tried using replace to change the “ AM” and “ PM” combinations to their equivalent with the narrow non breaking space (provided as a unicode escape I supposed, I read it’s hard to find a way to type it).

The less immediate workaround is to change the data model, it’s odd to store a date as US formatted string, given that most data sources offer Timestamp or an equivalent data type?

Cheers
Andrea

3

Hi Andrea,

many thanks for your investigation.
I knew that Geoserver couldn’t solve this problem. I just wanted to share my workaround.

The ${feature.datum.value} in the freemarker template results in the String e.g.
”Jan 23, 2022, 1:13:00 PM” (with a narrow non breaking space between 1:13:00 and PM).
The datum field in the postgres table is a timestamp without time zone type.

I solved the unparseable date error by replacing the blank space with this narrow non breaking space character. Following your hint to use unicode escape this looks like:

${feature.datum.value?datetime(“MMM dd, yyyy, h:mm:ss\x202Fa”)}

Using this format string in the datetime built-in, no error is thrown.

Using <#setting datetime_format=“dd.MM.yyyy HH:mm”>
I solved to get my timestamp in the output as 23.01.2022 13:50

Stefan