Problem, motivation
We need separate fields (on entity edit forms) depending on what kind of date / time would be added:
- date
- date and time
- date range
- date range with time
- date range all day
Imagine that we have en event content type. An editor adds event nodes to the site. But one event has only a date, an other has a date and a start time, a third one has start date and time and end date and time is important too. If we want to make possible all of these (and other) variations we have to add a lot of different date fields to the event content type. And it is problematic because of more reasons, eg.
- The user wants to add one information only but she will be provided a lot of fields to chose from.
- An event is meaningless without date, but the site builder can't set the date mandatory because just one of the fields is mandatory.
Proposed resolution
Make it more user friendly! ;) Eg. add a supplementary module which provide a select list of date types and displays the selected field only. The defauld field should be able to selected and it should automatically "know" if more date fields added to the same entity (but it should be possible to excluded date fields too). Also it should be able to set a rule that the entity can't be saved without filling one of its selectable fields.
An other solution would be to make the fields themselves more flexible. Eg. I add just a date range field with date and time, but it would be possible to fill it partially: eg. just the start date, or the start date and time etc. But I think there is a – programming related – reason why this is not possible already.
Comments
Comment #2
thamasComment #3
mpdonadioI don't want to discount the need for this (it is real), but there are a few things we need to keep in mind as we ponder this.
Storage for date, date+time, daterange, and daterange+time are all different (all day is really a special case of daterange+time). As we found when developing the original daterange patch, this made things very complicated, especially when you consider extreme time zones (cf, the patch that adjusted how date-only fields are interpreted).
We do have an issue to make the end_value optional on daterange fields. It is currently postponed, pending wrapping up improved views and better timezone support. I think we will want to move on this, but after we wrap up those two.
A practicality of having a date+time, but only allowing one potion to be entered, is that there is the text version of the field (the date and time parts), but these also contain computed internal fields that are based on \Datetime, so need to be proper date+time. Dateonly gets away with this by using noon as the time portion, along with some shenanigans.
Do-it-all fields are essentially unmaintainable. A new option bubbles into the field widgets, the formatters, and into views. And, all of the option combos needs to be tested.
We will have to make the decision of what we want in core vs what can (and should) live in contrib.
Comment #4
thamasmpdonadio thanks for sharing all this background information. I understand that it is problematic to solve in the backend but if we want a flexible solution there definitely must be a solution to make it user friendly.
It may live in contrib depending on how much it is needed.
Comment #5
thamasComment #8
Peter Törnstrand CreditAttribution: Peter Törnstrand commentedDoes anyone know if there is any work done on this in contrib? If so could you please point me in the right direction.
Comment #9
yareckon CreditAttribution: yareckon commentedHere is the Meta issue you want to chime it on if this is important to you: #2543958: [META] DateTime Module Improvements
Comment #10
yareckon CreditAttribution: yareckon commentedComment #11
thamas@Peter Törnstrand
We use a custom solution (not available to others yet). It is based on more individual date fields (for start date(s) and for end date) and a default time is automatically set when the user do not want to set it.
Comment #14
brad.bulger CreditAttribution: brad.bulger commentedThe problem we are seeing, coming to move an existing D7 site, is that delegating features to "contrib" ends up with a distinct field type for each feature. Which leaves us exactly in the place originally described here. We need to be able to make entries that may or may not have times, may or may not extend for a range of time, may or may not recur. To create separate fields that cover all the possible cases, and then somehow make it so that this group is required without any particular one of them being required... For our users, this is a significantly less useful and more annoying experience. Not to mention all the complications involved with views, exports, etc. to go from one field to many many fields that still represent one value from the user's perspective.
Comment #15
geek-merlinMy gut feeling is, making the core field(s) more polymorphic will not happen. So the canonical approach might be to have a paragraph field and a paragraph type for every field variant.
Comment #22
DamienMcKennageek-merlin's suggested approach might end up being the easiest, just because date data is rather complicated.
Maybe when Drupal 10 has native JSON data storage we could reconsider this, because then we could use JSON selection rules.