-
Notifications
You must be signed in to change notification settings - Fork 17
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
Date replace and Date get #433
base: draft
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.
Not a big fan of the _component
suffix, otherwise just added a couple of minor comments to clean-up the descriptions. Overall very solid proposals, I think.
Has this been tested against common date-time libraries, especially the ones that are mentioned in the implementation guide? It would be good to know whether all the edge cases have been found, documented and been tested with at least the 4 libraries mentioned there (this is the reason for the change request).
Co-authored-by: Matthias Mohr <[email protected]>
Co-authored-by: Matthias Mohr <[email protected]>
Co-authored-by: Matthias Mohr <[email protected]>
Okay
Not really. What implementation guide? |
https://github.com/Open-EO/openeo-processes/blob/master/meta/implementation.md |
You're not a fan of |
date_get and date_replace seem fine to me, but I'm not the dictator so if many prefer the _component suffix, I'm fine with it. I don't have a good alternative at hand (maybe "part"), I also don't think we hve anything comparable right now, which we can borrow from. |
the closest comparable process is |
date_replace_component and date_get_component is more intuitive to me than date_replace, date_get and date_element. |
@m-mohr , if there is no further review of this then kindly approve. |
@soxofaan 👆🏾 |
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.
no further remarks from me, we already iterated enough on this on I guess :)
Sure, thanks. |
@PondiB You did never followed-up on the comment with regards to extending the implementation guide. Any updates on that? |
"minute", | ||
"hour", | ||
"day", | ||
"day of week", |
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.
Is day of week Monday or Sunday based? Does it start with 0 or 1? Does it return numbers or strings?
"day of week", | ||
"day of year", | ||
"week", | ||
"week number", |
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.
zero or one based? What's the difference between week and week number?
}, | ||
{ | ||
"name": "component", | ||
"description": "The component for the value given. The following pre-defined components are available:\n\n- millisecond: Milliseconds\n- second: Seconds .\n- minute: Minutes\n- hour: Hours\n- day: Days - changes only the the day part of a date\n- day of week: Day of Week\n- day of year: Day of Year\n- week: Weeks (equivalent to 7 days)\n- week number: Week Number\n- month: Months\n- year: Years\n\nReplacements with the component `year`, `month` or `day` do never change the 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.
The description needs to be made much more precise with regards to value ranges for example. See comments below.
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.
Did a quick review. See comments above. Also, the implementation guide on what libraries support exactly this should be added (compare to the other date processes).
Cool, thanks. I'll address them later. |
Implementation for issue #254
closes #254