If you have a date range configured to only store dates, and you use the daterange_duration widget, you get sort of confusing UI behavior.
A) If you define a date with the start as '2020-08-18' and say you want the duration to be '1 day', the widget (which was written to assume datetime, not just date) thinks the duration is an offset, and saves the end time as 2020-08-19. This isn't what users (the non-nerds who don't count from 0) expect. ;) If I say "1 day" I'd expect the start and end on the same day. If I say "2 days", starting today, I'd expect it to end tomorrow. Etc.
B) The widget settings still let you pick a duration granularity less than 1 day, which makes no sense for fields of this type.
For date-only range fields:
A) Always remove 1 day from the specified duration when computing the end date. When computing the default value for the widget, always add a day. That way, we always treat the 'duration' as the quantity of days in the range, not an 'offset' from the 1st day.
B) Enforce that the duration granularity is 1-day minimum, hide hours, minutes + seconds from the widget settings.
UI makes more sense for date-only ranges, where the 'duration' is a quantity of days in the range, not an offset from the starting date.
TBD, hopefully none.
None. We're not storing anything differently, just tweaking the UI of the widget.
Fixed
1.0
daterange_duration widget
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Automatically closed - issue fixed for 2 weeks with no activity.