Hi, we have a postgres+posgis database using a column of type Date. Using geoserver we define a time.ftl for parsing and display the info in the format dd/MM/yy using ${feature.fc_res.value?date(“dd/MM/yy”)} but when the year is less than 1930 WMS GetFeatureInfo request returns some like dd/MM/20yy (append 20 to the year). Changing the type from Date to Timestamp theres no problems so i think is a geoserver problem handling the Date type.
Somebody else has experiment that issue??
TY
Hi,
I’m not sure, but I believe there is something going on with the usage of the Freemarker
built-in formatting functions.
See here, the bottom of the page actually suggests not to use those built-ins with formatting patterns:
http://freemarker.org/docs/ref_builtins_date.html
Have you tried using …?string(pattern) instead?
The behavior you’re seeing seems consistent with the Java date parsing rules when given
only two digits for the year… but I don’t know why they are being applied in your case:
“For parsing with the abbreviated year pattern (“y” or “yy”), SimpleDateFormat must interpret the abbreviated year relative to some century. It does this by adjusting dates to be within 80 years before and 20 years after the time the SimpleDateFormat instance is created. For example, using a pattern of “MM/dd/yy” and a SimpleDateFormat instance created on Jan 1, 1997, the string “01/11/12” would be interpreted as Jan 11, 2012 while the string “05/04/64” would be interpreted as May 4, 1964. During parsing, only strings consisting of exactly two digits, as defined by Character.isDigit(char), will be parsed into the default century. Any other numeric string, such as a one digit string, a three or more digit string, or a two digit string that isn’t all digits (for example, “-1”), is interpreted literally. So “01/02/3” or “01/02/003” are parsed, using the same pattern, as Jan 2, 3 AD. Likewise, “01/02/-3” is parsed as Jan 2, 4 BC.”
Cheers
Andrea
On Wed, Oct 14, 2015 at 4:31 PM, Fde_G . <federicogodan2000@anonymised.com> wrote:
Hi, we have a postgres+posgis database using a column of type Date. Using geoserver we define a time.ftl for parsing and display the info in the format dd/MM/yy using ${feature.fc_res.value?date(“dd/MM/yy”)} but when the year is less than 1930 WMS GetFeatureInfo request returns some like dd/MM/20yy (append 20 to the year). Changing the type from Date to Timestamp theres no problems so i think is a geoserver problem handling the Date type.
Somebody else has experiment that issue??
TY
Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
Ok, I redefine the rule as dd/MM/yyyy but the dates before 1930 now are show
as dd/MM/00yy...
i.e: 12/01/1929 -> 12/01/0029 and 12/01/2029 -> 12/01/0029.
feature.fc_res.value?date?string["dd/MM/yyyy"]
In the database the comun is defined as Date (without hour and sec)
Using feature.fc_res.value?string["dd/MM/yyyy"] just trow parsing errors...
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Date-parsing-problem-tp5230133p5232648.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
On Mon, Oct 26, 2015 at 7:27 PM, okusax <federicogodan2000@anonymised.com>
wrote:
Ok, I redefine the rule as dd/MM/yyyy but the dates before 1930 now are
show
as dd/MM/00yy...
i.e: 12/01/1929 -> 12/01/0029 and 12/01/2029 -> 12/01/0029.feature.fc_res.value?date?string["dd/MM/yyyy"]
In the database the comun is defined as Date (without hour and sec)
Using feature.fc_res.value?string["dd/MM/yyyy"] just trow parsing errors...
Parsing?... odd, which errors? I'd expect formatting ones, not parsing
ones.
No clue... what happens if you do a WFS request against that layer, how
does the output look like?
Cheers
Andrea
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
-------------------------------------------------------