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:

  1. Same day
  2. Same month
  3. Same year
  4. 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

  1. Finalize proposal
  2. Rewrite the code and upload a patch
  3. Review
  4. 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.

CommentFileSizeAuthor
#56 2834016-interdiff-54-56.txt1.46 KBFeyP
#56 2834016-56.patch66.6 KBFeyP
#54 2834016-interdiff-51-54.txt3.92 KBFeyP
#54 2834016-54.patch66.61 KBFeyP
#54 2834016-54-tests-only.patch66.58 KBFeyP
#51 2834016-51.patch65.8 KBerik.erskine
#47 Screen Shot 2020-05-13 at 5.06.11 PM.png70.81 KBjwilson3
#45 Screen Shot 2020-05-13 at 4.41.48 PM.png20.27 KBjwilson3
#45 Screen Shot 2020-05-13 at 4.41.08 PM.png41.74 KBjwilson3
#45 Screen Shot 2020-05-13 at 4.35.40 PM.png16.76 KBjwilson3
#45 Screen Shot 2020-05-13 at 4.41.08 PM.png41.74 KBjwilson3
#41 2834016-41.patch50.52 KBerik.erskine
#37 2834016-37.patch51.86 KBerik.erskine
#36 2834016-36.patch4.44 KBheddn
#28 2834016.18-28.interdiff.txt3.32 KBdww
#28 2834016-28.patch49.2 KBdww
#18 add_datetime_range-2834016-18.patch49.07 KBerik.erskine
#15 add_datetime_range-2834016-15.patch64.06 KBsorabh.v6
#15 add_datetime_range-2834016-15-interdiff.txt89.73 KBsorabh.v6
#12 add_datetime_range-2834016-12.patch76.52 KBsorabh.v6
#12 add_datetime_range-2834016-12-interdiff.txt86.53 KBsorabh.v6
#7 daterange.png52.78 KBmarassa
#4 Add_datetime_range_formatter_2834016_4.patch13.96 KBeliasbrat
Command icon 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:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

eliasbrat created an issue. See original summary.

eliasbrat’s picture

Issue summary: View changes
mpdonadio’s picture

If you attach this as a patch, we can review it and get it into the module.

eliasbrat’s picture

@mpdonadio, path attached.

marassa’s picture

Wow, 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?

MrPeanut’s picture

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

marassa’s picture

FileSize
52.78 KB

I just entered your data and here's what I get - exactly what you expected:
none
I see that eliasbrat has been working on the widget since his last post - maybe there's some work in progress going on there?

MrPeanut’s picture

Hmm, 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).

John Pitcairn’s picture

Version: » 8.x-1.x-dev

I'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?

marassa’s picture

> 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 ;)

sorabh.v6’s picture

Assigned: Unassigned » sorabh.v6
sorabh.v6’s picture

Assigned: sorabh.v6 » Unassigned
Status: Needs work » Needs review
FileSize
86.53 KB
76.52 KB

Hi,

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

subhojit777’s picture

Status: Needs review » Needs work

Not going in depth of the code. Just a preliminary basic code review.

  • There is a patch file inside the patch file
  • The module name has the same machine name as the parent module
subhojit777’s picture

@sorabh.v6 Maybe you should name the module as daterange_compact

sorabh.v6’s picture

Status: Needs work » Needs review
FileSize
89.73 KB
64.06 KB

@subhojit777 Removed patchfile from patchfile ;) Also made a sub-module for daterange formatter. Please review

heddn’s picture

Status: Needs review » Needs work

I can look at it more later, but some quick feedback.

  1. +++ b/modules/contrib/datetime_extras/LICENSE.txt
    @@ -0,0 +1,339 @@
    diff --git a/modules/contrib/datetime_extras/README.md b/modules/contrib/datetime_extras/README.md
    
    diff --git a/modules/contrib/datetime_extras/README.md b/modules/contrib/datetime_extras/README.md
    new file mode 100644
    
    new file mode 100644
    index 0000000..9b64122
    
    index 0000000..9b64122
    --- /dev/null
    
    --- /dev/null
    +++ b/modules/contrib/datetime_extras/README.md
    
    +++ b/modules/contrib/datetime_extras/README.md
    +++ b/modules/contrib/datetime_extras/README.md
    @@ -0,0 +1,4 @@
    
    @@ -0,0 +1,4 @@
    +Datetime Extras
    +===============
    +
    +Extends core Datetime and Datetime Range functionality.
    diff --git a/modules/contrib/datetime_extras/datetime_extras.info.yml b/modules/contrib/datetime_extras/datetime_extras.info.yml
    
    diff --git a/modules/contrib/datetime_extras/datetime_extras.info.yml b/modules/contrib/datetime_extras/datetime_extras.info.yml
    new file mode 100644
    
    new file mode 100644
    index 0000000..f6d995e
    
    index 0000000..f6d995e
    --- /dev/null
    
    --- /dev/null
    +++ b/modules/contrib/datetime_extras/datetime_extras.info.yml
    
    +++ b/modules/contrib/datetime_extras/datetime_extras.info.yml
    +++ b/modules/contrib/datetime_extras/datetime_extras.info.yml
    @@ -0,0 +1,13 @@
    
    @@ -0,0 +1,13 @@
    +name: 'Datetime Extras'
    +type: module
    +description: 'Extends core Datetime and Datetime Range functionality.'
    +# version: VERSION
    +# core: 8.x
    +dependencies:
    +  - drupal:datetime
    +
    +# Information added by Drupal.org packaging script on 2017-03-24
    +version: '8.x-1.x-dev'
    +core: '8.x'
    +project: 'datetime_extras'
    +datestamp: 1490394489
    

    There's too many folders in here. This should be from a git clone of datetime_extras itself, not of a d8 full site.

mpdonadio’s picture

Also, no need for a submodule for a formatter; just add it to the main module. Thanks!

erik.erskine’s picture

I 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 from daterange_compact to datetime_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:

  • what should the config entity be called? Does it need to contain this module's name in it somewhere?
  • what should the plugin be called? Does the machine name need to contain this module's name in it?
erik.erskine’s picture

Status: Needs work » Needs review
mpdonadio’s picture

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

marassa’s picture

As 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?

erik.erskine’s picture

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

marassa’s picture

Hi Erik, thanks for fast feedback.

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

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.

bespoke behaviour: content is created with an arbitrary time, and that time is then ignored under certain conditions (the two dates are the same)

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.

Ideally the content wouldn't be best stored like this, but as date + optional time

Probably.

however I'm not aware of a way to do that

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.

dww’s picture

Title: Add Datetime Range formatter » Add 'Compact' datetime range formatter

+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

mpdonadio’s picture

Sorry for missing some of the questions

what should the config entity be called? Does it need to contain this module's name in it somewhere?

Hmmm. Think I think 'datetime_extras_compact_format' is safest for a config ID.

what should the plugin be called? Does the machine name need to contain this module's name in it?

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.

dww’s picture

Status: Needs review » Needs work

@mpdonadio: Thanks for the replies.

Needs work to rename things per #25.

Re: adding a new issue component:

  1. Edit the project node, e.g. https://www.drupal.org/node/2756385/edit
  2. Scroll down to vertical tabs at the bottom of the page.
  3. Open the "Issues" vtab.
  4. Add/rearrange components as appropriate.
  5. Click "Save"
  6. Rejoice.

Cheers,
-Derek

dww’s picture

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

dww’s picture

Still needs renaming, but this at least applies cleanly again.

dww’s picture

Looking 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

dww’s picture

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

dww’s picture

Title: Add 'Compact' datetime range formatter » [PP-1] Add 'Compact' datetime range formatter
Status: Needs work » Postponed
Parent issue: » #3026314: Standardize naming conventions for plugins, config IDs, classes, etc

Before 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

dww’s picture

Category: Task » Feature request
Issue summary: View changes

Given 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

dww’s picture

If 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?

dww’s picture

Title: [PP-1] Add 'Compact' datetime range formatter » Add 'Compact' datetime range formatter
Status: Postponed » Needs work

#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

jonathanshaw’s picture

+1 to all your proposals @dww

heddn’s picture

Here's an alternative formatter that seems to arrive at the same rendering in a lot less code.

erik.erskine’s picture

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

Some of [the related issues listed in #31] 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)? ;)

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.

dww’s picture

@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

erik.erskine’s picture

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

Yes 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

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.

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 :)

dww’s picture

@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

erik.erskine’s picture

Here'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:

  • separators are hardcoded at the moment, although they could be defined in the formatter, as core does. There is some logic on whether spaces are added, namely if the thing either side has spaces or not. So 11 May - 12 May will have a space, whereas 11-12 will not.
  • it doesn't drop :00 minutes as described in #2959067: Option to conditionally drop minutes (when :00) and am/pm from time. But that isn't specific to date ranges.
  • no shortening of 9pm-10pm to 9-10pm (yet), but neither can #37 (yet!)
jwilson3’s picture

Probably 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?

dww’s picture

Yes, 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

jwilson3’s picture

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

jwilson3’s picture

I'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)

jwilson3’s picture

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

jwilson3’s picture

Issue summary: View changes
FileSize
70.81 KB

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

erik.erskine’s picture

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

I'm building a new Drupal 8 site, and trying to solve this specific problem (yet again) for another client.

Can I ask how you've solved this previously?

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.

Noted. That doesn't sound right.

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

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.

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.

Thanks for the concrete example - we can put that in a test :)

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.

How would expect these sort of open-ended ranges to be rendered?

jwilson3’s picture

Can I ask how you've solved this previously?

With DateRange_Compact (the D8 project was developed in 2018 and 2019).

How would expect these sort of open-ended ranges to be rendered

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.

erik.erskine’s picture

For 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 and timestamp field types.

MrPaulDriver’s picture

Regarding 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?

erik.erskine’s picture

Thanks @MrPaulDriver

The setting for ‘Omit minutes and seconds when zero’ does not appear to work

Ok, keen to see that. Can you export the .yml file for the config entity and share it? What field type was this?

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.

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.

This feature request is specifically for datetime_range, so I wonder if the datetime_extras module should make datetime_range a dependency?

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.

FeyP’s picture

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

The last submitted patch, 54: 2834016-54-tests-only.patch, failed testing. View results

FeyP’s picture

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

erik.erskine’s picture

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

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.

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.

FeyP’s picture

Status: Needs review » Closed (won't fix)

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

apaderno’s picture

Status: Closed (won't fix) » Needs review

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