Provide formatter options to choose what elements to output

Thanks for raising this, and for providing a merge request. I can see a couple of issues, though:

• Instead of unsetting the end value, please set it to the start value. Smart Date will output it as a single value, but having the array key present will prevent PHP notices from being thrown
• If you're adding to the formatter configuration options, that new option should also be added to smart_date.schema.yml

My first reaction to your approach was that perhaps it would be better to make this a set of radio buttons with options for how to output the values, including options for range, start with duration, and start only. That would allow us to remove the duration formatter, which would make ongoing maintenance a little easier, but it would require some non-trivial refactoring, as well as update hook, to fix any existing sites using the duration formatter. So I'm OK with forgoing all of that for now, but I'll probably open a child issue for that once this issue is resolved.

May I suggest a solution used by the Wordpress The Event Calendar Plugin?

They have a configuration value called something like "same day cuttoff time" which will suppress the end date display and only display end time if the end datetime is the next day and before the cuttoff time.

Example with a "cuttoff time" of 3am.
"Jan 1st, 2021 | 10:00pm - Jan 2nd, 2021 2:00am" would render as

"Jan 1st, 2021 | 10:00pm - 2:00am"

but

"Jan 1st, 2021 | 10:00pm - Jan 2nd, 2021 3:00am" would render as shown

@deckblad interesting suggestion, but I don't think it directly relates to this issue. Please file that as its own feature request.

Hi @mandclu. I've created a patch as per your suggestions in #7. I know best practice is to create patches against the latest dev branch, but I couldn't see a dev branch for 3.5.x so I created the patch against 3.5.1. I hope this is not a problem. If it is please let me know how to proceed and I'll gladly update.

Could you review and let me know if anything else is needed?

Thanks,
Pablo

I was searching for this feature too. Patch from #10 did not yield the result I expected. It just put out something like "20.07.2022 16.45 - 20.07.2022 16.45". I expected to have only the startdate put out, so "20.07.2002 16.45".

I suppose the startdate should be set equal enddate earlier in the preparation of the output.

So I am attaching an amended patch doing this.

sorry, silly mistake.

Apologies if it feels like this is hijacking an issue with a different intent, but I think that rather than have multiple formatters intended to display parts of the range, it would be better to add a configuration option to the standard formatter to choose which elements to display.

Options could include:
- Start
- End
- Duration

So, a site could use the one formatter to output all three, the start only, or whatever combination suits their needs. The recurring formatter could add options for recurrence rule, etc.

Moving this into the plan for Smart Date 4.0

Here's a patch to implement the approach proposed in #13. Feedback would be greatly appreciated.

LOL would help if I actually attached the patch.

Since the 4.0.x branch is still in alpha, I decided to go ahead and merge this in. Still, any feedback is welcome.

I think there's a bug in the viewElements function. I end up with an empty elements array when using smart date with recurring events. The "parts" setting comes back as $parts = [0 => 'start', 1 => 'end'] instead of the key value pairs the code is expecting $parts = ['start' => 'start', 'end' => 'end'] and so I never get a formated date set.

Might be that checkbox's field definition don't return key/value pairs? Just the array of checked values?

In any case, I had to add something like this so I wouldn't get an error using Date Augment Content

    // Drupal's field settings don't come back as key/value pairs for the parts.
    // Add the keys so that the key/value pairs to match except when value is
    // false.
    foreach ($parts as $key => $part) {
      if ((bool) $part && $key != $part) {
        $parts[$part] = $part;
        unset($parts[$key]);
      }
    }

I'll post a patch in a few to give a better idea what I'm talking about.

Here's the patch. I'm not particularly fond of the solution but I needed to demo something this afternoon and was the quickest way to get it working.

My setup includes the following modules:

  Field types                       Datetime (datetime)                                                                                      Enabled    9.5.3            
  Field types                       Datetime Range (datetime_range)                                                                          Disabled   9.5.3            
  Datetime                          Date Augmenter (date_augmenter)                                                                          Enabled    1.0.0            
  Date Augmenter                    Date Content Augmenter (date_content)                                                                    Enabled    1.0.0-alpha5     
  Duet Date Picker                  Duet Date Picker (duet_date_picker)                                                                      Enabled    1.0.0-alpha3     
  Field types                       Smart Date Recurring (smart_date_recur)                                                                  Enabled    4.0.0-alpha2     
  Field types                       Smart Date (smart_date)                                                                                  Enabled    4.0.0-alpha2 

And I get that error when trying to add date content to a recurring item.

Anyways, hopefully that helps. If you need more info or want a better solution let me know.

@minorOffense Thanks for identifying this, and for providing a fix. I haven't personally encountered the error you encountered, but normalizing the array to match the expected structure seems like a sensible approach. I had originally used in_array checks instead of a boolean test of the parts in question, and thought about refactoring the code to go back to that. In the end I decided that the code as currently written is much more readable, so I expanded on your approach to also ensure that an array key exists for each expected part, to avoid warnings when they evaluated later on.