Clarify that server implementations may accept shortened RFC 3339 time stamps (e.g., yyyy-mm or yyyy-mm-dd)

[jerstlouis]

From #185

7.2.4 - How should the Content-Datetime: value be encoded in case of an interval? How can I encode temporal information that are not valid according to RFC3339? (e.g. 2020-01 until 2021-01)?

Thanks for spotting that, I guess I did not realize that RFC 3339 does not seem to cover time period at all. The intent was to follow the same syntax as the datetime parameter in Features (and Common) which cites RFC 3339 section 5.6. The intent is to use the / separator. For your particular example, couldn't you encode that as 2020-01-01 / 2020-12-31 ?

[nmtoken]

So the intent is to follow ISO 8601 (which RFC 3339 is a profile of)

[jerstlouis]

@nmtoken The intent is to require that servers accept an instant as specified in RFC 3339 section 5.6, but include a permission that servers may also support shortened time strings where for eaxmple for a time interval like 2020-01-01/2020-12-31 the "end" of 2020-12-31 is implied.

Not to require servers to support the full ISO 8601.

This may require more discussion.

[pebau]

ISO 8601, WMS and others do it this way.

• Timestamps:

"2023"
"-1000000" 
"2023-01"
"2023-01-01"
"2023-01-01T10"
"2023-01-01T10:15"
"2023-01-01T10:15:22.345" 
"2023-01-01T10Z"  
"2023-01-01T10:15CET" 

• Durations:

"P1d" = 24 hours
"P1dT1h" = 25 hours
"PT05h" = 5 hours 
"2023-01-01 PT6h" = 2023-01-01T06

...so no invention of new microsyntax like "A / B" needed.

[jerstlouis]

@pebau The discussion here is about allowing exactly (some of) those shorter syntax in instants.

The A / B syntax is specific to the datetime parameter, which is a building block introduced in OGC API - Features.

It is a convenience alternative to the subset=time("A":"B") for users/clients familiar with that syntax.

[nmtoken]

"A/B" isn't an invented new microsyntax, it's part of ISO 8601 (time interval)

2020-03-16T14:02:18Z/2025-01-08T13:00:00Z
2023-01-01T10:15:22.345/P1dT1h

would be valid examples

[pebau]

ok, I stand corrected on this.

[chris-little]

@jerstlouis The danger here is that RFC 3339 is specifically and precisely about timestamps. They are fully ordered, so that logic can be applied (e.g. A is before B, or A is between B and C) but subtracting them to get a duration of an interval is not guaranteed to give the correct results.

ISO8601 should give the correct results as it mandates UTC and the Gregorian calendar, so leap seconds are accounted for. Whether they are actually accounted for in implementations is another question, usually extremely hard to answer. The ISO 8601 periodic/duration notation sidesteps this issue somewhat.

That probably doesn't help! ;-)

[strobpr]

just spotted this, had seen similar discussions elsewhere and it is a puzzling subject!
Firstly: all notions of time that I know are inherently intervals (or zones)! Even a microsecond.

That raises the question that if you use them as delimiters of larger zones, is it the beginning, the end, or any other, even arbitrary, 'point' within that zone that counts?

Example:
2020-03-16T14:02:18Z/2025-01-08T13:00:00Z Does that include the first and the last second or does it go from beginning of first to beginning of last? If it is 'somewhere within' then 2024/2025 could be an interval anywhere between 2 nanoseconds (or less) and 2 years.

BTW we need clarity especially for yearly intervals, Can we write just 2025 or do we have to write 2025/P1y or 20250101/20251231?

[jerstlouis]

@strobpr as provided by a client, timestamps may appear either:

• as a single time instant on their own for a slicing operation, either with the convenience datetime={instant} parameter or as part of a subset: subset=time("{instant}"), or
• as part of a time interval for a trim operation, again either with datetime={start}/{end} syntax, or as a subset trim: subset=time("{start}":"{end}")

When used as a slice, the shortened value represents the earliest start of whichever period the remaining components specify.

When used as the start of a trim, the shortened value makes the interval start at the earliest possible start of the specified timestamp components.

When used as the end of a trim, the shortened value makes the interval end at the latest possible end of the specified timestamp components.

2020-03-16T14:02:18Z/2025-01-08T13:00:00Z

That starts at the start of the 18th second and ends at the end of the 00th second.

2024/2025

That represents a full 2 years interval.

Can we write just 2025 or do we have to write 2025/P1y or 20250101/20251231?

For a trim, 2025/2025, 2025-01/2025-12 and 2025-01-01/2025-12-31 are what is valid and represent the entire year 2025.

The P1Y syntax is only used in the collection description's temporal extent to specify the temporal resolution.

2025 is a slice operation at the 00th second on 2025-01-01T00:00:00.000Z.

Also note that even when requesting a 'slice' of a 2D+ time coverage as a 2D format (e.g., GeoTIFF), there is a permission allowing to 'fill the gaps' with values not exactly at that time slice or within the region of validity / span of the cell.

[strobpr]

Do I read that correctly: even though time indications are inherently intervals, the convention says they can only be used as instances ('points'), whereby their exact position on the time axis depends on the syntax (operation)?

Simply speaking '2025' is not the whole year but some point between the beginning and the end depending on where it appears.

[jerstlouis]

@strobpr I believe what you are saying is correct, but it is not the simplest way to understand it :)

Time instants are provided in two contexts: slicing and trimming.

Slicing by definition expects a single instant, while trimming implies an interval given by two time instants.

So in the context of trimming, the full interval inherent to each of the two specified times instant is considered, adding its own thickness to the overall interval definition.

[jerstlouis]

SWG 2025-04-23: Editing actions:

• Clarify that for subsetting temporal dimensions servers are allowed to understand a shortened form of RFC 3339 (permission)
• Clarify that in this context the meaning of a shortened form in the different contexts (with examples):
  • datetime=2020-01/2020-12 start of a trimming interval: beginning of the interval (represented by the time string)
  • datetime=2020-01/2020-12 end of a trimming interval: end of the interval (represented by the time string)
  • datetime=2020-01 slicing instant: start of the interval (represented by the time string)
• This applies when using either subset=time(...)or datetime=