Time interpretation and processing

[tomkralidis]

We've run into some issues with how time is processed (i.e. see #2154, for example), and this had led to figuring out the best way to interpret and subsequently process time values when doing temporal querying.

The two main problems are:

• inclusive vs. exclusive: if sos_offering_timeextent is defined as "2006/2007", an event time of 2007-10-01/2007-10-30 (really passed as a GML TimePeriod, but trying to be brief/simple here) does NOT fall within the range, and no data is returned. Should it? My interpretation of "2007" would mean _any_ data from 2007-01-01/2007-12-31, the general rule being that, for a given time definition, all children of the last level of granularity of time defined are included

• validating time ranges: if sos_offering_timeextent is defined as "2006/2007", an event time of 2005-10-01/2007-10-30 (really passed as a GML TimePeriod, but trying to be brief/simple here) does NOT fall within the range, and no data is returned. Although the range comparison is not an exact match, there is a common window of time between the two time defs

We'll want to a./ agree on what is inclusive and what is not

I hope I explained this clearly.

[tomkralidis]

We'll want to a./ agree on what is inclusive and what is not and b./ implement any changes if necessary. I think changes are needed to validating time ranges regardless.

Keep in mind this may/should/will affect other time implementations.

[assefa]

Tom,

I believe the time structure is initialized at the begging and then updated using the time string that is read. Time like 2007 ends up being interpreted as 2007-01-01. I am not sure if this is a wring interpretation. I believe time/date fields in postgres would do the same?

[assefa]

Tom,.is this still an issue?

[tomkralidis]

Assefa: after looking at this again, the interpretation is correct.