Skip to content
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

Collection: Open intervals for temporal extents #1127

Merged
merged 2 commits into from
May 11, 2021
Merged

Collection: Open intervals for temporal extents #1127

merged 2 commits into from
May 11, 2021

Conversation

m-mohr
Copy link
Collaborator

@m-mohr m-mohr commented May 10, 2021

Related Issue(s): #1125

Proposed Changes:

  1. An open date range to both sides is now allowed in the Collection's temporal extents.

PR Checklist:

  • This PR is made against the dev branch (all proposed changes except releases should be against dev, not master).
  • This PR has no breaking changes.
  • I have added my changes to the CHANGELOG
    or a CHANGELOG entry is not required.
  • This PR affects the STAC API spec,
    and I have opened issue/PR #XXX to track the change.

@m-mohr m-mohr added this to the 1.0.0-rc.4 milestone May 10, 2021
@m-mohr m-mohr requested a review from cholmes May 10, 2021 20:46
@m-mohr m-mohr linked an issue May 10, 2021 that may be closed by this pull request
@@ -202,12 +202,17 @@ Clients only interested in the overall extent will only need to access the first
It is recommended to only use multiple temporal extents if a union of them would then include a large
uncovered time span (e.g. only having data for the years 2000, 2010 and 2020).

Each inner array consists of exactly two dates and times, each in UTC.
Each date and time MUST be formatted according to [RFC 3339, section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6).
Each inner array consists of exactly two elements, either a timestamp or `null`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we use "datetime" most places in the text instead of "timestamp" -- I always think of unix epoch milliseconds when I see timestamp.

Copy link
Collaborator Author

@m-mohr m-mohr May 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the explanation below it should be clear, right?

Timestamps consist of a date and time in UTC and MUST be formatted according to RFC 3339...

It's a bit strange to write "Datetimes consist of a date and time" below...

Update years in example.
Open date ranges are supported by setting either the start or the end time to `null`.
Example for data from the beginning of 2019 until now: `[["2009-01-01T00:00:00Z", null]]`.
Open date ranges are supported by setting the start and/or the end time to `null`.
Example for data from the beginning of 2019 until now: `[["2009-01-01T00:00:00Z", null]]`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be:
Example for data from the beginning of 2019 until now: [["2019-01-01T00:00:00Z", null]]``

@cholmes cholmes merged commit a553f11 into dev May 11, 2021
@cholmes cholmes deleted the issue-1125 branch May 11, 2021 15:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Collection: Open intervals for temporal extents
4 participants