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

thamas created an issue. See original summary.

thamas’s picture

Issue summary: View changes
mpdonadio’s picture

I 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.

thamas’s picture

mpdonadio 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.

thamas’s picture

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Peter Törnstrand’s picture

Does anyone know if there is any work done on this in contrib? If so could you please point me in the right direction.

yareckon’s picture

Here is the Meta issue you want to chime it on if this is important to you: #2543958: [META] DateTime Module Improvements

yareckon’s picture

thamas’s picture

@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.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

brad.bulger’s picture

We will have to make the decision of what we want in core vs what can (and should) live in contrib.

The 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.

geek-merlin’s picture

My 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.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

DamienMcKenna’s picture

geek-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.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.