From a537368b51500149bd973921581076f9ddf86988 Mon Sep 17 00:00:00 2001
From: Clemens Portele <portele@interactive-instruments.de>
Date: Thu, 11 Apr 2019 11:29:23 +0200
Subject: [PATCH 1/6] edits for first issue (no periods in RFC 3339)

---
 core/openapi/parameters/time.yaml                  |  2 +-
 core/standard/annex_ats.adoc                       | 14 +++++++-------
 .../requirements/core/REQ_fc-time-response.adoc    |  4 ++--
 openapi-buildings.yaml                             |  2 +-
 openapi.yaml                                       |  2 +-
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/core/openapi/parameters/time.yaml b/core/openapi/parameters/time.yaml
index 26348ed5..0efff2a3 100644
--- a/core/openapi/parameters/time.yaml
+++ b/core/openapi/parameters/time.yaml
@@ -1,7 +1,7 @@
 name: time
 in: query
 description: >-
-  Either a date-time or a period string that adheres to RFC3339. Examples:
+  Either a date-time or a period string. Date and time expressions adhere to RFC 3339. Examples:
 
   * A date-time: "2018-02-12T23:20:50Z"
   * A period: "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z" or "2018-02-12T00:00:00Z/P1M6DT12H31M12S"
diff --git a/core/standard/annex_ats.adoc b/core/standard/annex_ats.adoc
index da446536..9c20f77d 100644
--- a/core/standard/annex_ats.adoc
+++ b/core/standard/annex_ats.adoc
@@ -41,7 +41,7 @@ The WFS 3.0 standard does not mandate a standard format for the API Description
 
 ==== A.2.3 Resource Encodings
 
-The WFS 3.0 standard does not mandate a standard encoding for resources returned by the API. Yet a compliance test requires some minimal level of expected behavior. Therefore, this Abstract Test Suite asserts that the API returns resources encoded in HTML and GeoJSON. Since no compliance test suite exists for these encodings at this time, the resources shall be presented to the test operator for human inspection.  
+The WFS 3.0 standard does not mandate a standard encoding for resources returned by the API. Yet a compliance test requires some minimal level of expected behavior. Therefore, this Abstract Test Suite asserts that the API returns resources encoded in HTML and GeoJSON. Since no compliance test suite exists for these encodings at this time, the resources shall be presented to the test operator for human inspection.
 
 ==== A.2.4 Processing Security Objects
 
@@ -181,7 +181,7 @@ Each feature collection operation SHALL support a parameter time with the follow
 Tests: A.4.4.13 +
 | *Requirement 23:* Feature Collection Operation Time Parameter Response +
 Only features that have a temporal geometry that intersects the timestamp or time period SHALL be part of the result set, if the time parameter is provided. +
-The temporal information is either a date-time or a period string that adheres to RFC3339. +
+The temporal information is either a date-time or a period string. Date and time expressions adhere to RFC 3339. +
 If a feature has multiple temporal properties, it is the decision of the server whether only a single temporal property is used to determine the extent or all relevant temporal properties. +
 Tests: A.4.4.13 +
 | *Requirement 24:* Feature Collection Response +
@@ -250,7 +250,7 @@ none
 
 ====== c) Test Method:
 
-. All compliance tests shall be configured to use the HTTP 1.1 protocol exclusively.  
+. All compliance tests shall be configured to use the HTTP 1.1 protocol exclusively.
 
 ====== d) References:
 Requirement 7
@@ -462,7 +462,7 @@ None
 ===== A.4.4.1 Validate /api path
 
 ====== a) Test Purpose:
-Validate API definition provided through the /api path it the athoritative definition of this API.  Validate that this resource exists at the expected location and that it complies with the appropirate schema. 
+Validate API definition provided through the /api path it the athoritative definition of this API.  Validate that this resource exists at the expected location and that it complies with the appropirate schema.
 
 ====== b) Pre-conditions:
 * A URL to the server hosting the API definition document is known
@@ -470,9 +470,9 @@ Validate API definition provided through the /api path it the athoritative defin
 ====== c) Test Method:
 
 . Issue an HTTP GET request to the URL {server}/api
- 
+
 . Validate that a document was returned with a status code of 200
- 
+
 . Validate the returned document against the OpenAPI 3.0 schema
 
 ====== d) References:
@@ -802,7 +802,7 @@ Validate the Get Feature Operation Response.
     - To the Feature Collection which contains this Feature
 
     - Alternate encodings of this document in every other media type as identified by the compliance classes for this server.
-    
+
 . Validate that all links include the rel and type link parameters.
 
 ====== d) References:
diff --git a/core/standard/requirements/core/REQ_fc-time-response.adoc b/core/standard/requirements/core/REQ_fc-time-response.adoc
index 834bd3e9..e607d4a2 100644
--- a/core/standard/requirements/core/REQ_fc-time-response.adoc
+++ b/core/standard/requirements/core/REQ_fc-time-response.adoc
@@ -5,8 +5,8 @@
 Only features that have a temporal geometry that intersects the timestamp or
 time period SHALL be part of the result set, if the `time` parameter is provided.
 
-The temporal information is either a date-time or a period string that
-adheres to RFC 3339.
+The temporal information is either a date-time or a period string. Each date
+and time expression SHALL adhere to RFC 3339.
 
 If a feature has multiple temporal properties, it is the decision of the
 server whether only a single temporal property is used to determine
diff --git a/openapi-buildings.yaml b/openapi-buildings.yaml
index e6b23140..84f432d2 100644
--- a/openapi-buildings.yaml
+++ b/openapi-buildings.yaml
@@ -298,7 +298,7 @@ components:
       name: time
       in: query
       description: >-
-        Either a date-time or a period string that adheres to RFC 3339. Examples:
+        Either a date-time or a period string. Date and time expressions adhere to RFC 3339. Examples:
 
         * A date-time: "2018-02-12T23:20:50Z"
         * A period: "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z" or "2018-02-12T00:00:00Z/P1M6DT12H31M12S"
diff --git a/openapi.yaml b/openapi.yaml
index 00e33628..f8cc71ea 100755
--- a/openapi.yaml
+++ b/openapi.yaml
@@ -242,7 +242,7 @@ components:
       name: time
       in: query
       description: >-
-        Either a date-time or a period string that adheres to RFC 3339. Examples:
+        Either a date-time or a period string. Date and time expressions adhere to RFC 3339. Examples:
 
         * A date-time: "2018-02-12T23:20:50Z"
         * A period: "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z" or "2018-02-12T00:00:00Z/P1M6DT12H31M12S"

From 5b40a6ed0181db7169ed2eeab072274312be872a Mon Sep 17 00:00:00 2001
From: Clemens Portele <portele@interactive-instruments.de>
Date: Thu, 11 Apr 2019 11:32:24 +0200
Subject: [PATCH 2/6] edits for fourth issue (`date-time`, not `dateTime`)

---
 core/openapi/schemas/extent.yaml                   | 2 +-
 core/openapi/schemas/featureCollectionGeoJSON.yaml | 2 +-
 core/openapi/schemas/timeStamp.yaml                | 2 +-
 openapi-buildings.yaml                             | 6 +++---
 openapi.yaml                                       | 4 ++--
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/core/openapi/schemas/extent.yaml b/core/openapi/schemas/extent.yaml
index 29c6bcc5..ddbf61a3 100644
--- a/core/openapi/schemas/extent.yaml
+++ b/core/openapi/schemas/extent.yaml
@@ -43,7 +43,7 @@ properties:
     maxItems: 2
     items:
       type: string
-      format: dateTime
+      format: date-time
     example:
       - "2011-11-11T12:22:11Z"
       - "2012-11-24T12:32:43Z"
diff --git a/core/openapi/schemas/featureCollectionGeoJSON.yaml b/core/openapi/schemas/featureCollectionGeoJSON.yaml
index 0686778e..2caf5dae 100644
--- a/core/openapi/schemas/featureCollectionGeoJSON.yaml
+++ b/core/openapi/schemas/featureCollectionGeoJSON.yaml
@@ -17,7 +17,7 @@ properties:
       $ref: link.yaml
   timeStamp:
     type: string
-    format: dateTime
+    format: date-time
   numberMatched:
     type: integer
     minimum: 0
diff --git a/core/openapi/schemas/timeStamp.yaml b/core/openapi/schemas/timeStamp.yaml
index f60be76d..3a7eb8ec 100644
--- a/core/openapi/schemas/timeStamp.yaml
+++ b/core/openapi/schemas/timeStamp.yaml
@@ -1,4 +1,4 @@
 description: This property indicates the time and date when the response was generated.
 type: string
-format: dateTime
+format: date-time
 example: '2017-08-17T08:05:32Z'
diff --git a/openapi-buildings.yaml b/openapi-buildings.yaml
index 84f432d2..d0ecf3af 100644
--- a/openapi-buildings.yaml
+++ b/openapi-buildings.yaml
@@ -521,7 +521,7 @@ components:
           maxItems: 2
           items:
             type: string
-            format: dateTime
+            format: date-time
           example:
             - '2011-11-11T12:22:11Z'
             - '2012-11-24T12:32:43Z'
@@ -545,7 +545,7 @@ components:
             $ref: '#/components/schemas/link'
         timeStamp:
           type: string
-          format: dateTime
+          format: date-time
         numberMatched:
           type: integer
           minimum: 0
@@ -617,7 +617,7 @@ components:
               minimum: 1
             lastUpdate:
               type: string
-              format: dateTime
+              format: date-time
 tags:
   - name: Capabilities
     description: >-
diff --git a/openapi.yaml b/openapi.yaml
index f8cc71ea..21174f62 100755
--- a/openapi.yaml
+++ b/openapi.yaml
@@ -455,7 +455,7 @@ components:
           maxItems: 2
           items:
             type: string
-            format: dateTime
+            format: date-time
           example:
             - '2011-11-11T12:22:11Z'
             - '2012-11-24T12:32:43Z'
@@ -479,7 +479,7 @@ components:
             $ref: '#/components/schemas/link'
         timeStamp:
           type: string
-          format: dateTime
+          format: date-time
         numberMatched:
           type: integer
           minimum: 0

From a6fe8c971169220bb6464fdfbf5d3e8763604214 Mon Sep 17 00:00:00 2001
From: Clemens Portele <portele@interactive-instruments.de>
Date: Thu, 11 Apr 2019 11:42:44 +0200
Subject: [PATCH 3/6] edits for thrid issue (`datetime` instead of `time`)

---
 .../parameters/{time.yaml => datetime.yaml}        |  2 +-
 core/standard/annex_ats.adoc                       | 14 +++++++-------
 core/standard/clause_7_core.adoc                   | 10 +++++-----
 .../requirements/core/REQ_fc-numberMatched.adoc    |  2 +-
 .../requirements/core/REQ_fc-time-definition.adoc  |  4 ++--
 .../requirements/core/REQ_fc-time-response.adoc    |  2 +-
 openapi-buildings.yaml                             | 10 +++++-----
 openapi.yaml                                       |  8 ++++----
 8 files changed, 26 insertions(+), 26 deletions(-)
 rename core/openapi/parameters/{time.yaml => datetime.yaml} (95%)

diff --git a/core/openapi/parameters/time.yaml b/core/openapi/parameters/datetime.yaml
similarity index 95%
rename from core/openapi/parameters/time.yaml
rename to core/openapi/parameters/datetime.yaml
index 0efff2a3..83c3388c 100644
--- a/core/openapi/parameters/time.yaml
+++ b/core/openapi/parameters/datetime.yaml
@@ -7,7 +7,7 @@ description: >-
   * A period: "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z" or "2018-02-12T00:00:00Z/P1M6DT12H31M12S"
 
   Only features that have a temporal property that intersects the value of
-  `time` are selected.
+  `datetime` are selected.
 
   If a feature has multiple temporal properties, it is the decision of the
   server whether only a single temporal property is used to determine
diff --git a/core/standard/annex_ats.adoc b/core/standard/annex_ats.adoc
index 9c20f77d..6dfb31c0 100644
--- a/core/standard/annex_ats.adoc
+++ b/core/standard/annex_ats.adoc
@@ -177,10 +177,10 @@ The bounding box is provided as four or six numbers, depending on whether the co
 The coordinate reference system of the values SHALL be interpreted as WGS84 longitude/latitude (http://www.opengis.net/def/crs/OGC/1.3/CRS84) unless a different coordinate reference system is specified in a parameter bbox-crs. +
 Tests: A.4.4.12 +
 | *Requirement 22:* Feature Collection Operation Time Parameter +
-Each feature collection operation SHALL support a parameter time with the following characteristics (using an OpenAPI Specification 3.0 fragment): +
+Each feature collection operation SHALL support a parameter datetime with the following characteristics (using an OpenAPI Specification 3.0 fragment): +
 Tests: A.4.4.13 +
 | *Requirement 23:* Feature Collection Operation Time Parameter Response +
-Only features that have a temporal geometry that intersects the timestamp or time period SHALL be part of the result set, if the time parameter is provided. +
+Only features that have a temporal geometry that intersects the timestamp or time period SHALL be part of the result set, if the datetime parameter is provided. +
 The temporal information is either a date-time or a period string. Date and time expressions adhere to RFC 3339. +
 If a feature has multiple temporal properties, it is the decision of the server whether only a single temporal property is used to determine the extent or all relevant temporal properties. +
 Tests: A.4.4.13 +
@@ -200,7 +200,7 @@ Tests: A.4.4.10 +
 If a property timeStamp is included in the response, the value SHALL be set to the time stamp when the response was generated. +
 Tests: A.4.4.10 +
 | *Requirement 28:* Feature Collection Response numberMatched +
-If a property numberMatched is included in the response, the value SHALL be identical to the number of features in the feature collections that match the selection parameters like bbox, time or additional filter parameters. +
+If a property numberMatched is included in the response, the value SHALL be identical to the number of features in the feature collections that match the selection parameters like bbox, datetime or additional filter parameters. +
 A server MAY omit this information in a response, if the information about the number of matching features is not known or difficult to compute. +
 Tests: A.4.4.10 +
 | *Requirement 29:* Feature Collection Response numberReturned +
@@ -731,10 +731,10 @@ Validate the proper handling of the bbox parameter.
 ====== d) References:
 Requirements 20 and 21
 
-===== A.4.4.13 Time Parameter
+===== A.4.4.13 Date-Time Parameter
 
 ====== a) Test Purpose:
-Validate the proper handling of the time parameter.
+Validate the proper handling of the datetime parameter.
 
 ====== b) Pre-conditions:
 
@@ -743,9 +743,9 @@ successfully.
 
 ====== c) Test Method:
 
-. Verify that the OpenAPI document correctly describes the time parameter for the Get Features operation.
+. Verify that the OpenAPI document correctly describes the datetime parameter for the Get Features operation.
 
-. Repeat Test A.4.4.9 using different values for the time parameter.
+. Repeat Test A.4.4.9 using different values for the datetime parameter.
 
 . For each execution of Test A.4.4.9, repeat Test A.4.4.10 to validate the results.
 
diff --git a/core/standard/clause_7_core.adoc b/core/standard/clause_7_core.adoc
index 07232918..faac18f8 100644
--- a/core/standard/clause_7_core.adoc
+++ b/core/standard/clause_7_core.adoc
@@ -56,7 +56,7 @@ Accessing a `Collection` using HTTP GET returns a `CollectionResponse`. This
 response basically consists of features in the collection. The features included
 in the response are determined by the server based on parameters of the request.
 
-A `bbox` or `time` parameter may be used to select only a subset of the features in
+A `bbox` or `datetime` parameter may be used to select only a subset of the features in
 the collection (the features that are located in the bounding box or time period).
 
 The `limit` parameter may be used to request only a subset of the
@@ -541,14 +541,14 @@ A template for the definition of the parameter in YAML according to
 OpenAPI 3.0 is available at
 link:https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/core/openapi/parameters/bbox.yaml[bbox.yaml].
 
-==== Parameter time
+==== Parameter datetime
 
 include::requirements/core/REQ_fc-time-definition.adoc[]
 
 include::requirements/core/REQ_fc-time-response.adoc[]
 
 "Intersects" means that the time (instant or period) specified in the parameter
-`time` includes a timestamp that is part of the temporal geometry of the feature
+`datetime` includes a timestamp that is part of the temporal geometry of the feature
 (again, a time instant or period). For time periods this includes the start
 and end time.
 
@@ -591,7 +591,7 @@ a time period would match all features where the values overlap.
 
 A template for the definition of the parameter in YAML according to
 OpenAPI 3.0 is available at
-link:https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/core/openapi/parameters/time.yaml[time.yaml].
+link:https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/core/openapi/parameters/datetime.yaml[datetime.yaml].
 
 ==== Parameters for filtering on feature properties
 
@@ -763,7 +763,7 @@ A `400` will be returned in the following situations:
 * If query parameter `limit` is not an integer or not between minimum and maximum;
 * if query parameter `bbox` does not have 4 (or 6) numbers or they do not form
 a bounding box;
-* if parameter `time` is not a valid time stamp or time period.
+* if parameter `datetime` is not a valid time stamp or time period.
 
 
 === Feature
diff --git a/core/standard/requirements/core/REQ_fc-numberMatched.adoc b/core/standard/requirements/core/REQ_fc-numberMatched.adoc
index fa6a5658..847b02cc 100644
--- a/core/standard/requirements/core/REQ_fc-numberMatched.adoc
+++ b/core/standard/requirements/core/REQ_fc-numberMatched.adoc
@@ -4,7 +4,7 @@
 
 If a property `numberMatched` is included in the response, the value SHALL
 be identical to the number of features in the feature collections that match
-the selection parameters like `bbox`, `time` or additional filter parameters.
+the selection parameters like `bbox`, `datetime` or additional filter parameters.
 
 A server MAY omit this information in a response, if the information about the
 number of matching features is not known or difficult to compute.
diff --git a/core/standard/requirements/core/REQ_fc-time-definition.adoc b/core/standard/requirements/core/REQ_fc-time-definition.adoc
index adadb8bd..513e5417 100644
--- a/core/standard/requirements/core/REQ_fc-time-definition.adoc
+++ b/core/standard/requirements/core/REQ_fc-time-definition.adoc
@@ -2,12 +2,12 @@
 |===
 |*Requirement {counter:req-id}* |/req/core/fc-time-definition +
 
-Each feature collection operation SHALL support a parameter `time`
+Each feature collection operation SHALL support a parameter `datetime`
 with the following characteristics (using an OpenAPI Specification 3.0 fragment):
 
 [source,YAML]
 ----
-name: time
+name: datetime
 in: query
 required: false
 schema:
diff --git a/core/standard/requirements/core/REQ_fc-time-response.adoc b/core/standard/requirements/core/REQ_fc-time-response.adoc
index e607d4a2..95856757 100644
--- a/core/standard/requirements/core/REQ_fc-time-response.adoc
+++ b/core/standard/requirements/core/REQ_fc-time-response.adoc
@@ -3,7 +3,7 @@
 |*Requirement {counter:req-id}* |/req/core/fc-time-response +
 
 Only features that have a temporal geometry that intersects the timestamp or
-time period SHALL be part of the result set, if the `time` parameter is provided.
+time period SHALL be part of the result set, if the `datetime` parameter is provided.
 
 The temporal information is either a date-time or a period string. Each date
 and time expression SHALL adhere to RFC 3339.
diff --git a/openapi-buildings.yaml b/openapi-buildings.yaml
index d0ecf3af..ab0a0e34 100644
--- a/openapi-buildings.yaml
+++ b/openapi-buildings.yaml
@@ -131,7 +131,7 @@ paths:
       parameters:
       - $ref: '#/components/parameters/limit'
       - $ref: '#/components/parameters/bbox'
-      - $ref: '#/components/parameters/time'
+      - $ref: '#/components/parameters/datetime'
       - $ref: '#/components/parameters/function'
       responses:
         '200':
@@ -169,7 +169,7 @@ paths:
       parameters:
         - $ref: '#/components/parameters/limit'
         - $ref: '#/components/parameters/bbox'
-        - $ref: '#/components/parameters/time'
+        - $ref: '#/components/parameters/datetime'
         - $ref: '#/components/parameters/function'
       responses:
         '200':
@@ -294,8 +294,8 @@ components:
           type: number
       style: form
       explode: false
-    time:
-      name: time
+    datetime:
+      name: datetime
       in: query
       description: >-
         Either a date-time or a period string. Date and time expressions adhere to RFC 3339. Examples:
@@ -304,7 +304,7 @@ components:
         * A period: "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z" or "2018-02-12T00:00:00Z/P1M6DT12H31M12S"
 
         Only features that have a temporal property that intersects the value of
-        `time` are selected.
+        `datetime` are selected.
 
         If a feature has multiple temporal properties, it is the decision of the
         server whether only a single temporal property is used to determine
diff --git a/openapi.yaml b/openapi.yaml
index 21174f62..78895a2d 100755
--- a/openapi.yaml
+++ b/openapi.yaml
@@ -128,7 +128,7 @@ paths:
       - $ref: '#/components/parameters/collectionId'
       - $ref: '#/components/parameters/limit'
       - $ref: '#/components/parameters/bbox'
-      - $ref: '#/components/parameters/time'
+      - $ref: '#/components/parameters/datetime'
       responses:
         '200':
           description: >-
@@ -238,8 +238,8 @@ components:
           type: number
       style: form
       explode: false
-    time:
-      name: time
+    datetime:
+      name: datetime
       in: query
       description: >-
         Either a date-time or a period string. Date and time expressions adhere to RFC 3339. Examples:
@@ -248,7 +248,7 @@ components:
         * A period: "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z" or "2018-02-12T00:00:00Z/P1M6DT12H31M12S"
 
         Only features that have a temporal property that intersects the value of
-        `time` are selected.
+        `datetime` are selected.
 
         If a feature has multiple temporal properties, it is the decision of the
         server whether only a single temporal property is used to determine

From 7b31eb0756b157d1a0870c6e6f2fb03bccc4f94b Mon Sep 17 00:00:00 2001
From: Clemens Portele <portele@interactive-instruments.de>
Date: Thu, 11 Apr 2019 11:50:16 +0200
Subject: [PATCH 4/6] edits for third issue (`datetime` instead of `time`)

---
 core/standard/clause_7_core.adoc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/core/standard/clause_7_core.adoc b/core/standard/clause_7_core.adoc
index faac18f8..7aa988bb 100644
--- a/core/standard/clause_7_core.adoc
+++ b/core/standard/clause_7_core.adoc
@@ -556,7 +556,7 @@ and end time.
 =================
 February 12, 2018, 23:20:52 GMT:
 
-`time=2018-02-12T23%3A20%3A52Z`
+`datetime=2018-02-12T23%3A20%3A52Z`
 =================
 
 For features with a temporal property that is a timestamp (like `lastUpdate`
@@ -571,7 +571,7 @@ day or within the time period.
 =================
 February 12, 2018, 00:00:00 GMT to March 18, 2018, 12:31:12 GMT:
 
-`time=2018-02-12T00%3A00%3A00Z%2F2018-03-18T12%3A31%3A12Z`
+`datetime=2018-02-12T00%3A00%3A00Z%2F2018-03-18T12%3A31%3A12Z`
 =================
 
 .A period using start time and a duration
@@ -579,7 +579,7 @@ February 12, 2018, 00:00:00 GMT to March 18, 2018, 12:31:12 GMT:
 A duration of 1 month, 6 days, 12 hours, 31 minutes and 12 seconds from
 February 12, 2018, 00:00:00 GMT:
 
-`time=2018-02-12T00%3A00%3A00Z%2FP1M6DT12H31M12S`
+`datetime=2018-02-12T00%3A00%3A00Z%2FP1M6DT12H31M12S`
 =================
 
 For features with a temporal property that is a timestamp (like `lastUpdate`

From 67acc5d60b91c7537d0ba1cebe3706d413cd3d5d Mon Sep 17 00:00:00 2001
From: Clemens Portele <portele@interactive-instruments.de>
Date: Thu, 11 Apr 2019 12:45:16 +0200
Subject: [PATCH 5/6] edits for second issue (open ranges)

I have also removed support for duration expressions in Core as I have not seen them in use so far and they just complicate things for the server.
---
 core/openapi/parameters/datetime.yaml         | 10 +++--
 core/standard/annex_ats.adoc                  |  6 ++-
 core/standard/clause_7_core.adoc              | 38 +++++++++----------
 .../core/REQ_fc-time-response.adoc            | 24 ++++++++++--
 guide/conformance_checklist.md                |  2 +-
 guide/section_11_conformance_checklists.adoc  |  2 +-
 openapi-buildings.yaml                        |  8 +++-
 openapi.yaml                                  |  8 +++-
 8 files changed, 64 insertions(+), 34 deletions(-)

diff --git a/core/openapi/parameters/datetime.yaml b/core/openapi/parameters/datetime.yaml
index 83c3388c..52b43743 100644
--- a/core/openapi/parameters/datetime.yaml
+++ b/core/openapi/parameters/datetime.yaml
@@ -1,10 +1,14 @@
-name: time
+name: datetime
 in: query
 description: >-
-  Either a date-time or a period string. Date and time expressions adhere to RFC 3339. Examples:
+  Either a date-time or an interval, open or closed. Date and time expressions
+  adhere to RFC 3339. Open intervals are expressed using double-dots.
+
+  Examples:
 
   * A date-time: "2018-02-12T23:20:50Z"
-  * A period: "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z" or "2018-02-12T00:00:00Z/P1M6DT12H31M12S"
+  * A closed interval: "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z"
+  * Open intervals: "2018-02-12T00:00:00Z/.." or "../2018-03-18T12:31:12Z"
 
   Only features that have a temporal property that intersects the value of
   `datetime` are selected.
diff --git a/core/standard/annex_ats.adoc b/core/standard/annex_ats.adoc
index 6dfb31c0..a29db79e 100644
--- a/core/standard/annex_ats.adoc
+++ b/core/standard/annex_ats.adoc
@@ -180,8 +180,10 @@ Tests: A.4.4.12 +
 Each feature collection operation SHALL support a parameter datetime with the following characteristics (using an OpenAPI Specification 3.0 fragment): +
 Tests: A.4.4.13 +
 | *Requirement 23:* Feature Collection Operation Time Parameter Response +
-Only features that have a temporal geometry that intersects the timestamp or time period SHALL be part of the result set, if the datetime parameter is provided. +
-The temporal information is either a date-time or a period string. Date and time expressions adhere to RFC 3339. +
+Only features that have a temporal geometry that intersects the timestamp or time interval SHALL be part of the result set, if the datetime parameter is provided. +
+The temporal information is either a date-time or an interval. +
+The syntax of date-time is specified by RFC 3339, 5.6. +
+Open ranges in time intervals at the start or end are supported using a double-dot (`..`). +
 If a feature has multiple temporal properties, it is the decision of the server whether only a single temporal property is used to determine the extent or all relevant temporal properties. +
 Tests: A.4.4.13 +
 | *Requirement 24:* Feature Collection Response +
diff --git a/core/standard/clause_7_core.adoc b/core/standard/clause_7_core.adoc
index 7aa988bb..22a05b9f 100644
--- a/core/standard/clause_7_core.adoc
+++ b/core/standard/clause_7_core.adoc
@@ -57,7 +57,7 @@ response basically consists of features in the collection. The features included
 in the response are determined by the server based on parameters of the request.
 
 A `bbox` or `datetime` parameter may be used to select only a subset of the features in
-the collection (the features that are located in the bounding box or time period).
+the collection (the features that are located in the bounding box or time interval).
 
 The `limit` parameter may be used to request only a subset of the
 selected features and to indicate that the client wants to page through
@@ -547,14 +547,14 @@ include::requirements/core/REQ_fc-time-definition.adoc[]
 
 include::requirements/core/REQ_fc-time-response.adoc[]
 
-"Intersects" means that the time (instant or period) specified in the parameter
+"Intersects" means that the time (instant or interval) specified in the parameter
 `datetime` includes a timestamp that is part of the temporal geometry of the feature
-(again, a time instant or period). For time periods this includes the start
+(again, a time instant or interval). For time intervals this includes the start
 and end time.
 
 .A date-time
 =================
-February 12, 2018, 23:20:52 GMT:
+February 12, 2018, 23:20:52 UTC:
 
 `datetime=2018-02-12T23%3A20%3A52Z`
 =================
@@ -563,31 +563,31 @@ For features with a temporal property that is a timestamp (like `lastUpdate`
 in the building features), a date-time value would match all features where
 the temporal property is identical.
 
-For features with a temporal property that is a date or a time period,
+For features with a temporal property that is a date or a time interval,
 a date-time value would match all features where the timestamp is on that
-day or within the time period.
+day or within the time interval.
 
-.A period using a start and end time
+.Intervals
 =================
-February 12, 2018, 00:00:00 GMT to March 18, 2018, 12:31:12 GMT:
+February 12, 2018, 00:00:00 UTC to March 18, 2018, 12:31:12 UTC:
 
 `datetime=2018-02-12T00%3A00%3A00Z%2F2018-03-18T12%3A31%3A12Z`
-=================
 
-.A period using start time and a duration
-=================
-A duration of 1 month, 6 days, 12 hours, 31 minutes and 12 seconds from
-February 12, 2018, 00:00:00 GMT:
+February 12, 2018, 00:00:00 UTC or later:
+
+`datetime=2018-02-12T00%3A00%3A00Z%2F..`
+
+March 18, 2018, 12:31:12 UTC or earlier:
 
-`datetime=2018-02-12T00%3A00%3A00Z%2FP1M6DT12H31M12S`
+`datetime=..%2F2018-03-18T12%3A31%3A12Z`
 =================
 
 For features with a temporal property that is a timestamp (like `lastUpdate`
-in the building features), a time period would match all features where
-the temporal property is within the period.
+in the building features), a time interval would match all features where
+the temporal property is within the interval.
 
-For features with a temporal property that is a date or a time period,
-a time period would match all features where the values overlap.
+For features with a temporal property that is a date or a time interval,
+a time interval would match all features where the values overlap.
 
 A template for the definition of the parameter in YAML according to
 OpenAPI 3.0 is available at
@@ -763,7 +763,7 @@ A `400` will be returned in the following situations:
 * If query parameter `limit` is not an integer or not between minimum and maximum;
 * if query parameter `bbox` does not have 4 (or 6) numbers or they do not form
 a bounding box;
-* if parameter `datetime` is not a valid time stamp or time period.
+* if parameter `datetime` is not a valid time stamp or time interval.
 
 
 === Feature
diff --git a/core/standard/requirements/core/REQ_fc-time-response.adoc b/core/standard/requirements/core/REQ_fc-time-response.adoc
index 95856757..14a0d389 100644
--- a/core/standard/requirements/core/REQ_fc-time-response.adoc
+++ b/core/standard/requirements/core/REQ_fc-time-response.adoc
@@ -2,11 +2,27 @@
 |===
 |*Requirement {counter:req-id}* |/req/core/fc-time-response +
 
-Only features that have a temporal geometry that intersects the timestamp or
-time period SHALL be part of the result set, if the `datetime` parameter is provided.
+Only features that have a temporal geometry that intersects the temporal
+information in the `datetime` parameter SHALL be part of the result set,
+if the parameter is provided.
 
-The temporal information is either a date-time or a period string. Each date
-and time expression SHALL adhere to RFC 3339.
+The temporal information is either a date-time or an interval.
+The parameter value SHALL conform to the following syntax (using
+link:https://tools.ietf.org/html/rfc2234[ABNF]):
+
+```
+interval-closed     = date-time "/" date-time
+interval-open-start = "../" date-time
+interval-open-end   = date-time "/.."
+interval            = interval-closed / interval-open-start / interval-open-end
+datetime            = date-time / interval
+```
+
+The syntax of `date-time` is specified by
+link:https://tools.ietf.org/html/rfc3339#section-5.6[RFC 3339, 5.6].
+
+Open ranges in time intervals at the start or end are supported using a
+double-dot (`..`).
 
 If a feature has multiple temporal properties, it is the decision of the
 server whether only a single temporal property is used to determine
diff --git a/guide/conformance_checklist.md b/guide/conformance_checklist.md
index 7cb4e8fd..c0a1fee4 100644
--- a/guide/conformance_checklist.md
+++ b/guide/conformance_checklist.md
@@ -72,7 +72,7 @@ Derived from the [WFS 3.0, Part 1, version 3.0.0-draft.1](https://cdn.rawgit.com
     * [ ] "limit" parameter includes (changeable) "default"
     * [ ] "limit" parameter includes (changeable) "maximum"
   * [ ] "bbox" query parameter.  Only features intersecting this rectangle are returned.
-  * [ ] "time" query parameter.  Only features intersecting this time stamp or period are returned.
+  * [ ] "datetime" query parameter.  Only features intersecting this time stamp or interval are returned.
   * [ ] (recommended) For simple int/string properties of features include a querystring parameter with the property name to filter on.  For strings, wildcard matches may be useful in addition to simple equality.
 * [ ] Response includes links:
   * [ ] rel "self"
diff --git a/guide/section_11_conformance_checklists.adoc b/guide/section_11_conformance_checklists.adoc
index a34fe36d..76d9453a 100644
--- a/guide/section_11_conformance_checklists.adoc
+++ b/guide/section_11_conformance_checklists.adoc
@@ -74,7 +74,7 @@ Derived from the [WFS 3.0, Part 1, version 3.0.0-draft.1](https://rawcdn.githack
     * [ ] "limit" parameter includes (changeable) "default"
     * [ ] "limit" parameter includes (changeable) "maximum"
   * [ ] "bbox" query parameter.  Only features intersecting this rectangle are returned.
-  * [ ] "time" query parameter.  Only features intersecting this time stamp or period are returned.
+  * [ ] "datetime" query parameter.  Only features intersecting this time stamp or interval are returned.
   * [ ] (recommended) For simple int/string properties of features include a querystring parameter with the property name to filter on.  For strings, wildcard matches may be useful in addition to simple equality.
 * [ ] Response includes links:
   * [ ] rel "self"
diff --git a/openapi-buildings.yaml b/openapi-buildings.yaml
index ab0a0e34..780510a8 100644
--- a/openapi-buildings.yaml
+++ b/openapi-buildings.yaml
@@ -298,10 +298,14 @@ components:
       name: datetime
       in: query
       description: >-
-        Either a date-time or a period string. Date and time expressions adhere to RFC 3339. Examples:
+        Either a date-time or an interval, open or closed. Date and time expressions
+        adhere to RFC 3339. Open intervals are expressed using double-dots.
+
+        Examples:
 
         * A date-time: "2018-02-12T23:20:50Z"
-        * A period: "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z" or "2018-02-12T00:00:00Z/P1M6DT12H31M12S"
+        * A closed interval: "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z"
+        * Open intervals: "2018-02-12T00:00:00Z/.." or "../2018-03-18T12:31:12Z"
 
         Only features that have a temporal property that intersects the value of
         `datetime` are selected.
diff --git a/openapi.yaml b/openapi.yaml
index 78895a2d..7ac7e533 100755
--- a/openapi.yaml
+++ b/openapi.yaml
@@ -242,10 +242,14 @@ components:
       name: datetime
       in: query
       description: >-
-        Either a date-time or a period string. Date and time expressions adhere to RFC 3339. Examples:
+        Either a date-time or an interval, open or closed. Date and time expressions
+        adhere to RFC 3339. Open intervals are expressed using double-dots.
+
+        Examples:
 
         * A date-time: "2018-02-12T23:20:50Z"
-        * A period: "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z" or "2018-02-12T00:00:00Z/P1M6DT12H31M12S"
+        * A closed interval: "2018-02-12T00:00:00Z/2018-03-18T12:31:12Z"
+        * Open intervals: "2018-02-12T00:00:00Z/.." or "../2018-03-18T12:31:12Z"
 
         Only features that have a temporal property that intersects the value of
         `datetime` are selected.

From 0aad3be27bf9febb05472021134b5a5689257a69 Mon Sep 17 00:00:00 2001
From: Clemens Portele <portele@interactive-instruments.de>
Date: Tue, 16 Apr 2019 10:37:18 +0200
Subject: [PATCH 6/6] Update tests (inclusive ranges, fractions)

---
 core/standard/annex_ats.adoc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/core/standard/annex_ats.adoc b/core/standard/annex_ats.adoc
index a29db79e..48ed56ab 100644
--- a/core/standard/annex_ats.adoc
+++ b/core/standard/annex_ats.adoc
@@ -751,6 +751,8 @@ successfully.
 
 . For each execution of Test A.4.4.9, repeat Test A.4.4.10 to validate the results.
 
+. Use time intervals in the tests to verify the correct behavior for time intervals. In particular check that the start and end date-time are part of the interval (i.e. everything that is `>=` than the start and `<=` the end date-time is selected). Use also fractions of seconds in the tests.
+
 ====== d) References:
 Requirements 22 and 23