Move GeoServer's TimeParser code/parsing capabilities down to GeoTools

Description

GeoTools's ImageMosaic has a TimeParser mainly used to extract part of the filename and parsed as an ISO8601 String.
That TimeParser also supports some lenient variations to ISO8601.

For example, a standard date-time format:
yyyy-MM-dd'T'HH:mm:ss.SSS'Z'

has some supported alternatives:

  • yyyy-MM-dd'T'HHmmssSSS'Z'

  • yyyyMMdd'T'HH:mm:ss.SSS'Z'

  • yyyyMMdd'T'HHmmssSSS'Z'

  • yyyy-MM-dd'T'HHmmssSSS

  • yyyyMMdd'T'HH:mm:ss.SSS

  • yyyyMMdd'T'HHmmssSSS

  • ....
    due to different ways customers embed a date/time value as part of the filename.

Moreover, ImageMosaic's timeParser can return current time when "current" or "now" Strings are provided as time to be parsed.

GeoServer has its own TimeParser class having very similar code but with a few differences:

  • it doesn't support slight variations to ISO8601 format.

  • it throws an OWS ServiceException when the list of parsed times exceed a maximum value.

  • it supports a Fuzzy parsing allowing to deal with reduced accuracy date time.
    For example a dateTime like 2019-11 will be parsed as the whole month of November, starting from 2019-11-01T00:00:00.000Z to 2019-11-30T23.59.59.999Z

It would be great to merge these different classes into a single DateTimeParser class available at GeoTools level in order to avoid duplication of code and combine all the available capabilities into a single piece, that can be customized/enabled via flags.

The idea is to have GeoServer class extending the new one being moved into GeoTools so that it can still throw the OWS ServiceException when exceeding a max number of results and keep supporting strict ISO8601 formats. Whilst ImageMosaic will support lenient variations to ISO8601 formats too and gain the Fuzzy parsing on reduced accuracy date times.

Environment

None

Status

Assignee

Daniele Romagnoli

Reporter

Daniele Romagnoli

Triage

None

Fix versions

Affects versions

None

Components

Priority

Medium
Configure