- Issue created by @qichanghai
- last update
about 1 year ago 30,394 pass - @qichanghai opened merge request.
- Status changed to Needs review
about 1 year ago 3:45pm 12 October 2023 - Status changed to RTBC
about 1 year ago 6:48pm 12 October 2023 - 🇺🇸United States smustgrave
Change seems minimal. Searched for mainPropertyName in datetime and datetime_range and didn't find any so think should be good.
- last update
about 1 year ago 30,397 pass - last update
about 1 year ago 30,412 pass - last update
about 1 year ago 30,417 pass - last update
about 1 year ago 30,425 pass - last update
about 1 year ago 30,426 pass - last update
about 1 year ago 30,436 pass - last update
about 1 year ago 30,438 pass - last update
about 1 year ago 29,670 pass, 117 fail - last update
about 1 year ago 30,481 pass - last update
about 1 year ago 30,483 pass - last update
about 1 year ago 30,486 pass - last update
about 1 year ago 30,486 pass - last update
about 1 year ago 30,493 pass - last update
about 1 year ago 30,516 pass - last update
about 1 year ago 30,513 pass, 2 fail - last update
about 1 year ago 30,530 pass - last update
about 1 year ago 30,554 pass - last update
about 1 year ago 30,602 pass - last update
about 1 year ago 30,604 pass - last update
about 1 year ago 30,603 pass, 1 fail - last update
about 1 year ago 30,667 pass - last update
about 1 year ago 30,675 pass - last update
about 1 year ago 30,686 pass - last update
about 1 year ago 30,688 pass - last update
about 1 year ago 30,688 pass - Status changed to Needs work
about 1 year ago 9:23am 6 December 2023 - 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
This has big repercussions for anybody actually interacting with
DateRangeItem
fields today though!As the absolute minimum, this needs a change record.
And more likely: this needs to trigger a deprecation and can only start doing this in the future?
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
Also, this would be in direct conflict with ✨ Allow end date to be optional Needs review AFAICT? 🤔
- 🇩🇪Germany qichanghai Munich
Thanks @wim-leers. You are absolutely right. This might break the current behavior of
DateRangeItem
, in case the "value" is used as main property. I understood the datetime range as a way consistently managing range data so an end date is necessary, if it's not the case then we should just use the datetime field.And thank you for pointing out the conflict issue #2794481. If that issue is accepted then it further weakens my argument here, we just should not apply this change. But from issue #2794481 I see the change makes the responsibility of datetime and datetime_range even vague, and in my opinion cause more confusion. So I think we should keep this issue open, maybe someone can provide a clearer insight about the design decision.
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
+1 to keeping this open, and agreed that this field type is rather confusing! 😅