Problem/Motivation
Core's daterange formatter is verbose, and prints both start and end dates in full.
In most cases, this can be condensed, often drastically.
compact: 1-7 January 2019
core: 1 January 2019 - 7 January 2019
compact: 9am-5:30pm 19 January 2019
core: 9:00am 19 January 2019 - 5:30pm 19 January 2019
Proposed resolution
Add a field formatter for daterange fields, heavily based on daterange_compact, allowing admins to define different daterange formats for different conditions.
"Date/time range compact format" (daterange_compact_format) config entities. Includes label, ID, and patterns for different conditions:
- Same day
- Same month
- Same year
- Default
Each pattern has a start, separator, and end value. See #2959070: More flexible separators for why separators are per-pattern, not format-wide.
Possibly pattern-specific or format-wide settings for #2959067: Option to conditionally drop minutes (when :00) and am/pm from time, maybe others?
Include default formats for date and datetime ranges.
Names
Config entity ID: datetime_extras.daterange_compact_format
Formatter plugin ID: daterange_compact
Service: datetime_extras.daterange_compact.formatter
Classes / filenames:
src/DateRangeCompactFormatListBuilder.php
src/DateRangeCompactFormatter.php
src/DateRangeCompactFormatterInterface.php
src/Entity/DateRangeCompactFormat.php
src/Entity/DateRangeCompactFormatInterface.php
src/Form/DateRangeCompactFormatDeleteForm.php
src/Form/DateRangeCompactFormatForm.php
src/Plugin/Field/FieldFormatter/DateRangeCompactFormatter.php
tests/src/Functional/DateRangeCompactFormatterTest.php
Default config:
config/install/datetime_extras.daterange_compact_format.medium_date.yml
config/install/datetime_extras.daterange_compact_format.medium_datetime.yml
Remaining tasks
- Finalize proposal
- Rewrite the code and upload a patch
- Review
- Commit
User interface changes
New field formatter for daterange fields.
New admin routes to create + manage daterange_compact_format config entities.
API changes
New classes: config entities, forms, field plugin
New service: datetime_extras.daterange_compact.formatter
Data model changes
Config schema for daterange_compact_format config entities
Config schema for daterange_compact formatter settings
Release notes snippet
New daterange "Compact" field formatter with simple yet powerful "Date/time range compact format" config entities to condense output under different conditions.
Original report by @eliasbrat
Core Datetime Range module have not good format. It just use same formatter for start and end dates.
See more here: https://www.drupal.org/node/2833703
I created widget and formatter for this field and now we can show date on simple human readable format.
You can clone my code from github.
Comment | File | Size | Author |
---|---|---|---|
#56 | 2834016-interdiff-54-56.txt | 1.46 KB | FeyP |
#56 | 2834016-56.patch | 66.6 KB | FeyP |
| |||
#54 | 2834016-interdiff-51-54.txt | 3.92 KB | FeyP |
#54 | 2834016-54.patch | 66.61 KB | FeyP |
| |||
#54 | 2834016-54-tests-only.patch | 66.58 KB | FeyP |
Issue fork datetime_extras-2834016
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
eliasbrat CreditAttribution: eliasbrat as a volunteer and at FFW commentedComment #3
mpdonadioIf you attach this as a patch, we can review it and get it into the module.
Comment #4
eliasbrat CreditAttribution: eliasbrat as a volunteer and at FFW commented@mpdonadio, path attached.
Comment #5
marassa CreditAttribution: marassa commentedWow, was that fast! Thanks a lot, eliasbrat - I owe you a beer! ;)
In the perfect world the formatter should probably take base templates from whatever is set under "admin/config/regional/date-time/formats/" for the current language (like "F j" vs "j F" sequencing or 24 hour time vs am/pm) but for my personal use I can easily just tweak the code supplied. I would also like an option to prepend the day of week if it's a one-day range - also hopefully will manage myself.
PS The formatter works great, but when I tried to check out the widget I got the following upon trying to switch to "Manage Form Display":
Fatal error: Class 'Drupal\datetime_extras\Plugin\Field\FieldWidget\DateRangeWidgetBase' not found in C:\xampp\apps\drupal\htdocs\modules\datetime_extras\src\Plugin\Field\FieldWidget\DateRangeNiceWidget.php on line 24
Might be a config error on my side as I just downloaded your code from github into a new module directory - don't see any other released code under Datetime Extras module?
Comment #6
MrPeanut CreditAttribution: MrPeanut commentedI have an event that is January 10, 2017 from 1:00 p.m. to 3:00 p.m.
When I switched the formatter to Nice and Nice long, the date appears as January 10 - 10, 2017. (A) There is no time displayed and (B) the 10 appears twice.
Based on the original post at #2833703: Need a Datetime Range formatter removing redundant bits, I expected to see something like January 10, 2017, 1:00 - 3:00 p.m. Is that not covered in the code at https://github.com/eliasbrat/datetime_extras?
Comment #7
marassa CreditAttribution: marassa commentedI just entered your data and here's what I get - exactly what you expected:
I see that eliasbrat has been working on the widget since his last post - maybe there's some work in progress going on there?
Comment #8
MrPeanut CreditAttribution: MrPeanut commentedHmm, it appears as though the issue begins at 7:00 p.m. for me. (Ignore my original 1-3 p.m. comment.)
January 10, 2017 3:00 p.m. to January 10, 2017 6:59 p.m. displays as January 10, 2017 - 3:00 pm - 6:59 pm.
January 10, 2017 3:00 p.m. to January 10, 2017 7:00 p.m. displays as January 10 - 10, 2017.
I'm assuming this is due to time zones (Eastern is UTC-05:00).
Comment #9
John Pitcairn CreditAttribution: John Pitcairn commentedI'd like to draw attention to the work in daterange_compact, which I think achieves what is being attempted here.
Ultimately I think it might be desirable to include that in datetime_extras?
Comment #10
marassa CreditAttribution: marassa commented> I'd like to draw attention to the work in daterange_compact
Gave it a try, here's the result:
https://www.drupal.org/node/2890621
Unless I'm missing something obvious it simply does not do what Nice format does for me. I am all for more configurability but preferrably without throwing the baby out with the bathwater ;)
Comment #11
sorabh.v6Comment #12
sorabh.v6Hi,
I've created field formatter like one in daterange_compact as mentioned by @John Pitcairn in comment #9. Patchfile and interdiff is uploaded. Please review.
Thanks All
Comment #13
subhojit777Not going in depth of the code. Just a preliminary basic code review.
Comment #14
subhojit777@sorabh.v6 Maybe you should name the module as
daterange_compact
Comment #15
sorabh.v6@subhojit777 Removed patchfile from patchfile ;) Also made a sub-module for daterange formatter. Please review
Comment #16
heddnI can look at it more later, but some quick feedback.
There's too many folders in here. This should be from a git clone of datetime_extras itself, not of a d8 full site.
Comment #17
mpdonadioAlso, no need for a submodule for a formatter; just add it to the main module. Thanks!
Comment #18
erik.erskine CreditAttribution: erik.erskine commentedI had a look at the submodule that is included within the patch in #15. As mentioned in #9 it seems to be a copy of https://www.drupal.org/project/daterange_compact.
As the author of that module, I'd be happy to see it become part of
datetime_extras
where it can be better maintained (and the original module can be deprecated, directing people here). So thank you for considering making use of it! I agree with @mpdonadio that it doesn't warrant it's own submodule here though. With that in mind I've made a new patch that only includes the appropriate files fromdaterange_compact
todatetime_extras
. It also puts back the unit tests from that module.There are a few things to think about:
The formatter had a specific use case - to shorten the output by omitting the month/year if possible. If you don't need that, then the existing Default formatter in core's
datetime_range
module is sufficient. If we add it here, it it going to stay as a compact formatter, or become a more generic one that could end up replacing the core formatter?Answering that question will help with naming things:
Comment #19
erik.erskine CreditAttribution: erik.erskine commentedComment #20
mpdonadioThe current thought with datetime/daterange in core is to *just enough* to people to be able add date-related fields to entities, and basic view integration. We also want to avoid the do-it-all plugins; they are unmaintainable (see http://wimleers.com/article/simplicity-maintainability-cdn-module-drupal-8 for some similar thoughts).
datetime_extras is a place where we can iterate quickly on ideas and get them out.
So, this won't replace the core formatter.
Need to look at the patch, but won't be able to for a few days.
Comment #21
marassa CreditAttribution: marassa commentedAs an active user of both Nice formatter (formerly) and slightly modified Erik's Compact formatter (currently), I would like to "bump" my issue in this thread as well: https://www.drupal.org/node/2890621
The Compact formatter introduces two separate (and different) settings sections: one for Date only ranges and another for Date and time ranges, the latter providing no provision for compacting any ranges that don't start and end on the same day. This was an immediate show stopper for my use case as I have to use Date&time ranges for various kinds of events which can span hours or months, and if the range spans days or months I would still like to use "Same month" and "Same year" settings to compact my ranges. I added "Same month" and "Same year" support to the Date&time section and that's what I am using happily on my site right now, but as we are discussing simplicity and maintainability here, I can't help asking: do we really need two (now identical for me) settings sections for Date only and Date&time? Maybe one common section is enough applicable to both? Does anybody here have a real life use case that would warrant the use of two sections in the same format? Even if you do need different formats for Date only and Date&time ranges on your site, isn't it better to just create two differently named formats for the two cases, which the module allows?
Comment #22
erik.erskine CreditAttribution: erik.erskine commentedThe reason for separate date and datetime formats was to avoid the following scenario, which happens with the core date field:
1. user creates a date field (date only), and uses the default formatter to display that field
2. user creates some content with a date, say 27 July 2017
3. the content is rendered using the "medium" format which shows a date and a meaningless time of 12:00
The use case described in #2890621-3: Why no "Same month/year" formats for Date&time fields? involves some bespoke behaviour: content is created with an arbitrary time, and that time is then ignored under certain conditions (the two dates are the same). Ideally the content wouldn't be best stored like this, but as date + optional time, however I'm not aware of a way to do that.
Comment #23
marassa CreditAttribution: marassa commentedHi Erik, thanks for fast feedback.
4. User notices it and either modifies the "medium" format which is provided as a sample and obviously cannot fit all possible use cases or, better still, creates their own format to fit their needs.
Nothing horrible happened, in my book. Besides, the exact scenario you have described can happen to the simple (non-range) date field and nobody sees it as a problem. Nothing prevents a user from selecting (inadvertently or on purpose) a timeless format for a date and time field or a format with time for a date-only field.
The idea to have multiple named formats is brilliant, I just don't agree that each and every one of them must have two sections for date only and date&time fields. Core Date and Time formats don't have separate sections for those, they simply have different formats defined for different cases. And I can't see what warrants a different approach for the ranges.
That's exactly what happens when a user selects a timeless format for a simple date&time field if he doesn't care about the time in a particular context.
That was the simplest solution I was able to find for my use case, and I would appreciate any feasible alternatives.
Probably.
Neither am I. And I can't see how adding Same month/year handling would possibly harm anyone. If someone doesn't want to use it, they don't have to.
Comment #24
dww+1 to this. I need this, and I'm willing to help maintain it here instead of in a separate project.
#18 seems to be working fine with limited testing.
I'm in favor of calling this a 'Compact' formatter for datetime range fields, and naming things accordingly.
I'd also love feedback from datetime_extras maintainers about the answers to the rest of @erik.erskine's questions at #18.
I'm totally sympathetic to @ndlarge's concerns, and agree this could be simplified. +1 to #2890621: Why no "Same month/year" formats for Date&time fields?
We should move all the issues from the datetime_compact queue into here and triage. Perhaps add a 'Compact formatter' issue component to this project?
Thanks!
-Derek
Comment #25
mpdonadioSorry for missing some of the questions
Hmmm. Think I think 'datetime_extras_compact_format' is safest for a config ID.
I think 'daterange_compact' is fine in this case.
Adding a component is a good idea, but to be totally honest, I don't recall where that setting is for module.
Comment #26
dww@mpdonadio: Thanks for the replies.
Needs work to rename things per #25.
Re: adding a new issue component:
Cheers,
-Derek
Comment #27
dwwThis is now (mildly) conflicting with my patch at #2845081: Provide a datetime_range widget to define end time via a duration offset, since both are trying to add config/schema/datetime_extras.schema.yml.
See also #2887926-4: Make a stable release with security coverage
Thoughts?
Thanks!
-Derek
Edit: Retracted my -1. Sorry for the noise.
Comment #28
dwwStill needs renaming, but this at least applies cleanly again.
Comment #29
dwwLooking at the rename. @mpdonadio: confirming you want "datetime_extras_compact_format" (all underscores) not "datetime_extras.compact_format" (with a period) for the config ID. The second seems better to me, and more in line with everything else. Please advise.
Thanks,
-Derek
Comment #30
dwwOh wow, and the rename is going to be a huge PITA, since it touches all the Entity* code, class names, variables, etc. Ugh. ;)
Anyone else got time to take this on? This is turning into more of a project than I can crank out today. Sorry.
Comment #31
dwwBefore we get any further with this, I'd like to formalize our naming conventions in this project. Postponing this issue on #3026314: Standardize naming conventions for plugins, config IDs, classes, etc.
Meanwhile, I'd also like some direction on The Right Way(tm) to handle this issue vs. the stuff already in the daterange_compact queue that I also want to solve, ideally before we commit and officially release this here. In particular:
#2890621: Why no "Same month/year" formats for Date&time fields? (discussed above)
#2959067: Option to conditionally drop minutes (when :00) and am/pm from time
#2959070: More flexible separators
#2887922: Use protected not private to allow extending classes
...
Some of those are going to change the schema and structure of the format config entities. I do *not* want to be responsible for a ton of BC layer bloat and cruft around here, writing upgrade path tests and other related nonsense. ;) I do not intend to provide a migration path. Is that okay? Should I make a branch in here for this, push what we have now, and then commit fixes for the other issues as I plow forward? Should I just do that locally and upload new patches in here, not pushing anything into d.o's Git repo? Am I expected to make my own Github fork of datetime_extras where I can push WIP code (since that's what all the cool kids do)? ;) It seems counter-productive to spend time trying to "fix" the codebase @ daterange_compact, since so much of it is going to have to be rewritten/renamed for this issue here.
Thoughts? Help! ;)
Thanks,
-Derek
Comment #32
dwwGiven daterange_compact issues and the current codebase, here's my proposal for how this should be named and reorganized before we commit and release it. RFC.
Thanks!
-Derek
Comment #33
dwwIf we had something like #3021557: Make date_all_day a set of widgets and formatters for core's datetime_range field type we could update the field formatter to have 2 format settings: all-day vs. date-time, and it would know to use the right one.
Maybe we should do that anyway?
Comment #34
dww#3026314: Standardize naming conventions for plugins, config IDs, classes, etc is now in, so we have clear plan for how to name things. Yay.
Back to NW.
Would still love feedback on the ?s at the end of #31.
Cheers,
-Derek
Comment #35
jonathanshaw+1 to all your proposals @dww
Comment #36
heddnHere's an alternative formatter that seems to arrive at the same rendering in a lot less code.
Comment #37
erik.erskine CreditAttribution: erik.erskine commentedI've had another go at moving the code from
daterange_compact
to this module, as per #24.This is basically a big renaming of lots of things, as described in #32. Other than that, the code is largely the same with some tidying up of comments/variable names, and a few minor deprecation-related changes.
This patch doesn't (yet) address the other issues listed in #31. They are certainly valid, and hopefully easier now that the class/filenames fit
datetime_extras
.I ran into trouble with
datetime_extras.daterange_compact_format
being too long for a entity type ID: https://www.drupal.org/project/drupal/issues/1191434. That needs resolving somehow.A branch somewhere (Github?) sounds like a good idea. The scope of this particular issue is now quite large, like a meta issue. It would be nice to commit in stages to somewhere "unofficial", without the need for BC etc.
Comment #38
dww@heddn Re: #36 -- that's a lot less code, but it's got much less flexibility and functionality, and doesn't handle nearly the cases that the existing efforts do. Maybe we could make that another "daterange_compact_lite" formatter or something? ;) Can we move that to another issue, if you're interested in preserving that approach?
@erik.erskine Re: #37 Fantastic, thanks for moving this forward again! How about we make a sandbox fork of datetime_extras, and start committing the changes there? When we're happy, we can merge those commits back into this repo. We could also create a feature branch directly in this project, but then I'd have to give you commit access here, which I'm not sure you (or the other datetime_extras maintainers) want. Lemme know what you think, and I'd be happy to setup the sandbox.
Cheers,
-Derek
Comment #39
erik.erskine CreditAttribution: erik.erskine as a volunteer commentedYes please, that would be good. No need to add the patch in #37, I have a local branch with a series of small commits making up it's contents.
Should we move these related issues there too?
#2890621: Why no "Same month/year" formats for Date&time fields?
#2959067: Option to conditionally drop minutes (when :00) and am/pm from time
#2959070: More flexible separators
#2887922: Use protected not private to allow extending classes
I think that would be worse. Aside from the commit access, it seems Drupal issues aren't really ready for that kind of workflow yet:
#2488266: [META] Improve Git workflow on Drupal.org by implementing issue workspaces
Be good to get some traction on this again :)
Comment #40
dww@erik.erskine - sounds good. Here you go:
https://www.drupal.org/sandbox/dww/3132731
I just pushed the current state of the 8.x-1.x branch of datetime_extras to that and made you a co-maintainer.
Please commit/push whatever you want there and I'll take a look ASAP.
Meanwhile, I think we can leave the issues in the daterange_compact issue queue for now, until we actually merge it into here.
Thanks!
-Derek
Comment #41
erik.erskine CreditAttribution: erik.erskine as a volunteer commentedHere's an alternative (and completely different!) approach to that in #37 that may be worth considering.
This does away with the separate config entity for date range formats. Instead it interprets the pattern from a core date format and derives separate patterns for the start/end values, depending on whether individual date components can be combined. The permutations for this (same day, same month, same year etc) are the same as they are in #37. The field formatter is configured like the default one in core: you pick a core date format, but the output is shortened if possible.
A few points to note:
11 May - 12 May
will have a space, whereas11-12
will not.9pm-10pm
to9-10pm
(yet), but neither can #37 (yet!)Comment #42
jwilson3Probably the wrong place to post this, but I'm building a new Drupal 8 site, and trying to solve this specific problem (yet again) for another client. All the talk here about merging features covered by other date-related modules is leaving me wondering what the status is — it seems to all be bit of a work in progress (like this ticket is a great example). Ultimately the question will affect long term site maintenance — do I install daterange_compact or go with something more experimental like the patch on the ticket here with the expectation that this will (soonish?) work its way in and this module will end up stabilizing and becoming the one single go-to solution?
Comment #43
dwwYes, soonish this will be The Solution(tm). daterange_compact is basically abandoned at this point. The future is here, not there. I just don't have an exact timeframe for when the future is now. ;) But yes, I/we want to have 1 place to maintain this feature. Once it's in, that'll give us yet more reason to finish up #2887926: Make a stable release with security coverage, too.
Cheers,
-Derek
Comment #44
jwilson3Thanks for a super quick response when it counts Derek. Really appreciate that. I've also just realized that the other contributor on this issue (Erik) was/is the maintainer/creator of the DateRange_Compact module. So this makes sense. I was hesitating installing this module that is otherwise useless for my needs in order to get a feature that is in patch/concept form only. But I'll make an exception for this and hopefully client will understand when they see the alpha + patch. ;)
Cheers to both of you for combining forces and pushing things forward.
Comment #45
jwilson3I've tested patch in #41 and have two issues:
1) If you leave the Time zone override set to "- None selected -" (the default value) on the Manage Display tab for fields, it ends up defaulting to UTC instead of the website's default timezone, which is both confusing and doesn't follow precedent set by other datetime field formatters. If you end up selecting the default timezone, it shows the time zone on the frontend -- with is also unintended.
2) It is incompatible with the date_all_day module to hide times when they match a specific pattern (12:00:00 AM - 11:59:59 PM)
Comment #46
jwilson3Another issue with the approach taken by #41 is that you really lose the flexibility to specify different formats based on certain conditions, like you did with daterange_compact module.
For example. The long date format I setup on my site includes an
\a\t
before the time, which works for a single time, but for a same-day time range, "at 8:00am-2:00pm" doesn't make sense. It should rather be formatted as "from 8:00am to 2:00pm" which cannot be achieved with the approach in #41. Maybe it could be done with the approach in #37, I'm going to test this next.Comment #47
jwilson3Feedback on the approach at #37:
1) It does support what I want to do for a long format with "at 2:00pm" vs "from 8:00am to 2:00pm".
Given that this approach will have a much cleaner upgrade path from DateRange_Compact module, I'd recommend sticking with this and working out those additional feature requests on #39 within that context, which I think would be much easier to achieve than the approach taken on #41. Just my two cents. HTH.
2) However, #37 does not currently support the Optional_End_Date module. The date field is simply blank (not rendered on the front end) if I leave the end date blank on the date range field.
For #37 to be usable for me, it would need the Date_All_Day and Optional_End_Date module integration to be working.
Comment #48
erik.erskine CreditAttribution: erik.erskine as a volunteer commentedThanks for the feedback, @jwilson3. As Derek mentioned, this is where future work on this formatter is being done rather than in daterange_compact, but there won't be a upgrade path between the two. Even the config-based approach in #37 is quite different from that in daterange_compact.
Can I ask how you've solved this previously?
Noted. That doesn't sound right.
Agreed. The configuration (and corresponding UI) was starting to get quite complex, particularly once you consider extras like removing :00 from times, etc. I wanted to explore the possibility of a zero-config, install-and-forget approach that would work for the majority of use cases.
It feels clunky to have separate config entities for date range formats. Nor is it particularly intuitive that you have to create them first before you can use the formatter. I'm wondering if third party settings on the date format might work better.
Thanks for the concrete example - we can put that in a test :)
How would expect these sort of open-ended ranges to be rendered?
Comment #49
jwilson3With DateRange_Compact (the D8 project was developed in 2018 and 2019).
I just contributed a patch to FullCalendar_View module that added this support, it was pretty straightforward logic and amounts to just handling a case when then end date is null. See patch and interdiff on #2976922-8: Add functionality for all-day events. See also https://www.drupal.org/project/Optional_End_Date and ongoing core patch #2794481: Allow end date to be optional for more info.
Comment #51
erik.erskine CreditAttribution: erik.erskine as a volunteer commentedFor reference, here is a patch equivalent to the contents of the merge request in #50:
Description:
Here is a revised port of
daterange_compact
. It's close to the original module in that it introduces a new configuration entity with specific formats for same day, same month, same year ranges.Includes a couple of other features that have been requested previously, namely omitting minutes when they are zero, and omitting duplicate am/pm from a range.
Although primarily for ranges, the widget also handles
datetime
andtimestamp
field types.Comment #52
MrPaulDriver CreditAttribution: MrPaulDriver commentedRegarding the patch at #51
1. The 'compact' formatting works very well.
2. The setting for 'Omit minutes and seconds when zero' does not appear to work.
More generally;
Unless I am missing something, I believe the approach being taken is inappropriate because different field storage methods are required for each of the normal date display variations.
- All day
- Date only
- Date and time
If I understand correctly, a general purpose event content type would therefore require three separate date fields cover each of these normal date display needs. This seems wrong.
Aside. This feature request is specifically for datetime_range, so I wonder if the datetime_extras module should make datetime_range a dependency?
Comment #53
erik.erskine CreditAttribution: erik.erskine as a volunteer commentedThanks @MrPaulDriver
Ok, keen to see that. Can you export the .yml file for the config entity and share it? What field type was this?
If you mean we can’t have a field with a mix of date-only and date+time values in it, then I agree. But that's outside the scope of this though.
It’s not a dependency. It’s more akin to a field type module implementing views plugins/hooks: the field module will work without views installed; those plugins/hooks just go unused.
Comment #54
FeyP CreditAttribution: FeyP as a volunteer and at werk21 commentedThanks for this very nice field formatter, it works quite well!
With regards to #47 2) and your question in #48: I think it should be displayed as if start time and end time were identical. Since I needed that for a project, I added this on top of the existing MR. For now, I created patches against 8.x-1.x and an interdiff with 51. Let me know, if you think this is useful and you would like me to push those changes as individual commits to your MR.
Comment #56
FeyP CreditAttribution: FeyP as a volunteer and at werk21 commentedJust noticed something else: Except for the label, the configuration is not translatable. However, you would often need different date formats for different languages, so in my opinion they really should be.
Attached is a new patch that makes the configuration values of type string translatable. A container rebuild should be enough to apply the new config schema.
I would say that the boolean configuration values should be translatable also, however there are some core issues with config translation of boolean values and without core patches you would get exceptions and config schema mismatches upon saving the translated configuration, if the boolean values were marked as translatable, so for now I omitted this for a better user experience out of the box. This could be added later, once #2866303: UI missing for translatable data type unless form_element_class is set has been merged. Possible workarounds we could do now would be to use label as type for the boolean values or to provide our own form element class for the boolean type, but for now I didn't go down either route.
Comment #57
erik.erskine CreditAttribution: erik.erskine as a volunteer commented@FeyP thank you for your contribution (especially so, as it includes test coverage :)
We decided against merging this field formatter into datetime_extras in the end, and instead release version 2.0 of [daterange_compact](https://www.drupal.org/project/daterange_compact). Sorry for the confusion! The architecture of that module now closely resembles the changes described earlier on in this issue, namely a single set of patterns for both date and datetime.
That project now supports translation too.
Re optional end dates:
Feel free to chime in on #2970628: Add support for optional end dates. It was a long time since I looked at this. Since then, optional end date has gained a stable release so it'll hopefully be much clearer on how we should align with that module.
Comment #58
FeyP CreditAttribution: FeyP as a volunteer and at werk21 commentedThank you, I appreciate the info. I must say, that this is a little bit unfortunate for me. I was aware of the module, but opted for this patch instead as I was under the impression that the plan was to merge the module into datetime_extras and I wanted to use something sustainable, but that's just how it goes sometimes, I guess ;). I definitely have to look into how to migrate the sites I already setup to your module and I will also look into that issue regarding support for optional end dates at that time, but it probably will be a while until I can work on that. For now, let's close this issue as won't fix so that it actually represents the current state of affairs.
Comment #59
apadernoI am re-opening this issue, since it wasn't closed by a project maintainer.
There are 14 users who participated in this issue; the fact that one of them has different plans doesn't make this issue closed.