First of all, I'm very happy this module exists (although I haven't actually started testing it or looking at the code in detail). Thanks for solving this and sharing it!
However, based on the project page description and a quick skim, it's extremely unfortunate that this module is creating a whole new field type. That's going to further splinter the already evil D8 landscape of slightly different but incompatible field types, widgets and formatters for dates.
Yes, it's the only safe way to store the "all-day" bit as a separate field value, without simply overloading 00:00:00 to 23:59:59 and doing magic.
It'd be *way* better if this was simply a new set of widgets and formatters for the existing datetime and datetime_range field types.
Are you open to patches that convert this back into something closer to how this was solved in D7, so that it can work with any existing datetime* fields?
Thanks!
-Derek
p.s. Related point: see #3020179: Consider making "all day" option affect both start and end date -- there's no sense having separate checkboxes for the all-day-ness on start vs. end_value. Without that, there's less need for a separate field type.
| Comment | File | Size | Author |
|---|
Comments
Comment #2
bwoods commentedI will second this comment. I was working on a project a year ago that needed this, and now I'm back to looking into it again. A single "all-day" checkbox, from the admin user perspective, in conjunction with the existing formatters should do the trick. The all-day logic is already in the calendar code, so I just hacked that by having the client enter midnight for all-day events. If I have time in the coming weeks to test this, I'll post more (assuming I'm successful!).
Comment #3
Brian Weaver commentedThird!
We are trying to add this "All Day" functionality to existing sites, and a new field type requires a new field, which would require a data migration of the existing content, etc.
The module description says 'Extends datetime range fields to provide "All day" functionality', but it's actually a whole new field type. :(
Of course, as always, thanks for contributing this work to the Drupal community.
Comment #4
bwoods commentedI have a working prototype of this via a modded datetime_range module. I need to test a little more, but essentially there is one checkbox that toggles the ability to set time. If it works as expected, I'll post a patch (not positive if it will be added to core, but maybe it will!).
Comment #5
dww@bwoods: exciting! See #2734255: Support a per-instance "all-day" option for datetime and datetime range fields -- that's the core issue to upload such a patch to.
Thanks,
-Derek
Comment #6
akalam commentedI agree, I didn't like to have a new field with the needing of data migration, but since the field database structure needs modification I wasn't comfortable enough with the solution to prepare a patch to the core.
Of course I would be exited to help remotely to improve the core date fields.
Comment #7
akalam commentedI think solving this issue is the first step for applying to move it into core. Now that I finish preparing the field formatters I can start working on it.
Comment #8
akalam commentedSorry, I missed copied the formatters trait to a new folder but missed the old one. Attaching new patch.
Comment #9
akalam commentedWrong issue.
Comment #10
akalam commentedComment #11
akalam commentedComment #12
akalam commentedComment #14
akalam commentedThe widget and formatters are now available for daterange fields.
A hook_update is provided for transforming existing date_all_day fields into daterange fields.
I'm gonna update the module description to recommend users wanting to have optional end date feature to follow the #2794481: Allow end date to be optional issue.