-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support time window in the past in the APIexposure of data in the past is added #60
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One very small fix and one request for clarification please :)
Except that look good for me.
@population_density_data_retrievePopulationDensity_24_timeframe_crosses_request_time | ||
Scenario: Error 400 when startDate is set to a date in the past and the endDate is set to a date in the future | ||
Given the request body property "$.startDate" is set to a date in the past | ||
And the request body property "$.endDate" is set to a date in teh future |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
date in teh
--> date in the
@@ -294,7 +293,7 @@ components: | |||
Start date time. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) | |||
and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ | |||
(i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z) | |||
The minimum startTime is the time of the request. | |||
The minimum startTime must cover at least 3 months before the request time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not clear for me (but perhaps this is my English).
Do we mean that request in the past must query information older than 3 months or the contrary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My idea was to declare a minimal time frame everyone must support. I.e. everyone who implements API must support 3 months, if someone exposes 1 year - its a bonus.
What type of PR is this?
What this PR does / why we need it:
API definition is enhanced to support dates in the past as well as suggested in issue #51