Hello,
I’m currently invoking a WFS exposed by geoserver that interrogates a JDBC based layer.
The underlying table has a TIMESTAMP field, and the user interface can call the WFS using a time parameter.
So, if in the invocation we pass something like:
ogc:PropertyIsEqualTo
ogc:PropertyNameMY_TIMESTAMP</ogc:PropertyName>
ogc:Literal2016-04-18T10:00:00Z</ogc:Literal>
</ogc:PropertyIsEqualTo>
I would expect that my db record with MY_TIMESTAMP field set to ‘2016-04-18T10:00:00Z’ is returned, but this is not the case.
But if I pass something like:
ogc:Literal2016-04-18T10:00:00+02:00</ogc:Literal>
the result is returned:
gml:featureMember
<MY_FEATURE fid=“MY_FEATURE.62”>
62
<MY_TIMESTAMP>2016-04-18T10:00:00</MY_TIMESTAMP>
…
</MY_FEATURE>
</gml:featureMember>
It seems that the server does not care about the timezone of the database field but it considers the default timezone of the OS when evaluating an OGC filter.
This is strange, since the filter is in +02:00 TZ and the returned record is in UTC TZ
Now, I found that when launching the Geoserver in standalone mode, if I add the ‘-Duser.timezone=UTC’ to start parameters the problem disappears.
Another solution is to change the timezone on the hosting OS.
This can be a good solution if Geoserver runs in a dedicated VM or as a standalone process.
But how to deal with machines on which I can’t change the timezone because there are other running services?
And also, how to deal geoserver deployed into an Application Server?
Probably I can’t launch the AS with the ‘-Duser.timezone=UTC’ option since there are other services that exposes functionalities that would be compromised by this setting.
Am I facing a known issue or what? Any suggestion?
Thank you and best regards
Francesco Fornari
Java Tech Expert
ACS S.p.A.
Rome - ITALY