Last modified date not match with Tika

(from github.com/freestyle68)
Hi,
there is a problem with the Last Modified displayed date on results page.
Scanned some pdf on local system (protocol file:/…) and this field not match with date from pdf readers or from Tika 1.14 metadata.

Fess version 11.2.1, Debian 9 and Linux Mint as OS, Oracle Java 1.8.

I’ll give two examples:

file 1.pdf

Fess display: Last Modified: 2005-02-25 22:03

Okular: February 09, 2005 06:31:09 PM
Tika 1.14:
Last-Save-Date: 2005-02-09T18:31:09Z
dcterms:modified: 2005-02-09T18:31:09Z
meta:save-date: 2005-02-09T18:31:09Z
modified: 2005-02-09T18:31:09Z
pdf:docinfo:modified: 2005-02-09T18:31:09Z

file 2.pdf:

Fess display: Last Modified: 2004-01-22 21:59
Okular: January 13, 2004 08:06:03 PM
Tika 1.14:
Last-Modified: 2004-01-13T20:06:03Z
Last-Save-Date: 2004-01-13T20:06:03Z
dcterms:modified: 2004-01-13T20:06:03Z
meta:save-date: 2004-01-13T20:06:03Z
modified: 2004-01-13T20:06:03Z
pdf:docinfo:modified: 2004-01-13T20:06:03Z

Properties for Bug Report:
file.separator=/
file.encoding=UTF-8
java.runtime.version=1.8.0_131-b11
java.vm.info=mixed mode
java.vm.name=Java HotSpot™ 64-Bit Server VM
java.vm.vendor=Oracle Corporation
java.vm.version=25.131-b11
os.arch=amd64
os.name=Linux
os.version=4.9.0-3-amd64
user.country=US
user.language=en
user.timezone=Europe/Rome

I attach the two pdfs.

Thank you.

1.pdf
2.pdf

(from github.com/marevol)
Last Modified field is not Tika’s one.
It’s a file timestamp for file://… and LAST_MODIFIED header for http://…
Incremental crawling on Fess uses Last Modified data and does not touch the file content to reduce I/O.
If you want to use Tika’s date, you can add additional field to fess index.