Here's a couple of data points for this discussion:
http://mapserver.org/ogc/wms_time.html
MapServer has addressed this issue (see the section Interpreting Time
Values), but they seem to do different things depending on the back-end
data source. For PostGIS at least they use the "time as time window"
approach, by virtue of using the DB date_trunc function, which amounts to
the same thing). One takeaway from this: I would suggest we want a data
source-independent strategy.
http://augusttown.blogspot.ca/2010/03/two-ambiguities-about-time-in-ogc-wms.html
This blog post discuss the issue, and weighs in on the side of treating all
time values as time windows (with duration determined by precision). This
seems to make sense to me. Although, what then is meant by a TIME of
2012-06-01/2012-06-02". Is that the window including exactly June 1, or
does it include June 1-2 ?
On Mon, Jun 4, 2012 at 12:02 PM, Justin Deoliveira <[email protected]>wrote:
> Hi all,
>
> Recently a client reported an issue with how geoserver interprets the
> TIME parameter in a WMS request when a full precision timestamp is not
> specified. Referencing the WMS spec:
>
> <quote>
>
> D.2.1 Basic syntax
>
> The basic time format uses ISO 8601:2000 “extended” format: up to 14
> digits specifying century, year, month, day, hour, minute, and seconds, and
> optionally a decimal point followed by zero or more digits for fractional
> seconds, with non-numeric characters to separate each piece:
>
> ccyy-mm-ddThh:mm:ss.sssZ
>
> *The precision may be reduced by omitting least-significant digits*, as
> in the examples below. ISO 8601:2000 prefers a decimal comma before
> fractional seconds but allows a decimal period as in this International
> Standard. The century digits shall be included with the year; two-digit
> years shall not be used.
>
> A time zone suffix is mandatory if the hours field appears in the time
> string. All times should be expressed in Coordinated Universal Time (UTC),
> indicated by the suffix Z (for "zulu"). When a local time applies, a
> numeric time zone suffix as defined by ISO 8601:2004, 5.3.4.1 shall be
> used. The absence of any suffix at all means local time in an undefined
> zone, which shall not be used in the global network of map servers enabled
> by this International Standard.
>
> EXAMPLE 1 EXAMPLE 2 EXAMPLE 3 EXAMPLE 4
>
> ccyy Year only
> ccyy-mm Year and month
> ccyy-mm-dd Year, month and day ccyy-mm-ddThhZ Year, month, day and hour in
> UTC
>
> </quote>
>
> The part about omitting digits isn't all that clear to me. I *think* it
> means that when one supplies a less precise timestamp we should actually
> interpret that as a date range and match anything that lies between the
> specified timestamp and the next timestamp that results from "rolling" the
> time up to the next closest value? If that indeed is what is implied we
> don't implement it that way as far as I can tell.
>
> What do others think?
>
> -Justin
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
