Opened 17 years ago
Closed 13 years ago
#2196 closed defect (fixed)
Time interpretation and processing
Reported by: | tomkralidis | Owned by: | assefa |
---|---|---|---|
Priority: | normal | Milestone: | 6.0 release |
Component: | SOS Server | Version: | |
Severity: | normal | Keywords: | |
Cc: | assefa, cplist@…, dmorissette |
Description
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.
Change History (5)
comment:1 by , 17 years ago
comment:2 by , 16 years ago
Milestone: | 5.2 release → 5.4 release |
---|---|
Owner: | changed from | to
comment:3 by , 15 years ago
Milestone: | 5.6 release → 6.0 release |
---|
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?
comment:5 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Assefa: after looking at this again, the interpretation is correct.
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.