Why no "Same month/year" formats for Date&time fields?

@ndlarge thanks for reporting this. I'm trying to understand your use case a bit better. You say the field type allows for dates and times, but for some events you don't want to display the times. So when you create a multi-day event, what time values are you storing?

Would this problem go away if you were able to use the same field to store a mix of both date only and date+time values, optionally leaving the time blank?

Maybe it's better to discuss this here, instead of at #2834016-21: Add 'Compact' datetime range formatter and beyond...

Overall, I find ndlarge's perspective compelling. It seems like a *lot* of additional complication in this code and in various parts of the UI, to provide date-only vs. date-time sections within the same format. There will always be a separate formatter instance for different field types, so you can easily select different range formats for these two uses. Trying to reuse the exact same format for totally different date field types seems like the problem. And that's true of core, too, not just these compact date ranges.

What's the point in all the overhead of making separate format entities if we then try to make them so complex that you only ever configure one for your whole site? ;) At that point, it should have been a bunch of config knobs. ;) But no, you did the right thing by making flexible formats. Now we just have to finish the job and simplify them (but make them actually work for all the cases).

I'd propose:
- Massively simplify these config entities (and supporting code) by removing date-only vs. datetime distinction.
- Provide 4 options within each format:
-- default
-- same day
-- same month
-- same year
- Encourage sites to create multiple formats if they have a mix of date-only and date-time fields to deal with.

Yes, it's true that "same day" doesn't exactly make sense for a daterange of date-only fields. That'd be a daterange that starts and stops on the same day. In that case, you'd want no separator and no end date displayed at all (like the core widget does). If we fix #2959070: More flexible separators while we're at it, then we can completely cover this case, since the expected configuration for this would be something like:
start: 'Y-m-d'
separator: ''
end: ''

Am I missing something here? Is there a reason that life is better if you can reuse the same format for many different date field types? If I'm configuring a view, either I'm telling it to render entities (in which case I get the nice per-instance view mode stuff as configured / intended) or I'm rendering specific fields (in which case I know what field type I'm dealing with and can pick the right format accordingly).

Can anyone come up with a counter-example where re-using the same format across different field types is a win?

I'd like to clean this all up before this code moves into datetime_extras. Hoping to get agreement on how we want it to work going forward.

Thanks!
-Derek

RFC: I just posted a fleshed out proposal in an issue summary update to #2834016: Add 'Compact' datetime range formatter

If we're all happy with that, we can mark this issue fixed once that's done.

Thanks,
-Derek

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 formatter to have 2 format settings: all-day vs. date-time.
Maybe we should do that anyway?

Is there a reason that life is better if you can reuse the same format for many different date field types?

My reasoning for this was to try to avoid the following scenario which happens with the core date fields:

1. you create a date only field somewhere
2. you use the default "medium" format as provided by core
3. when you come to view content, it shows the date plus a time of 12:00

Ideally I'd have wanted to be able to restrict a particular format to either date-only or date+time fields, but that isn't possible. So this seemed like the next best thing - ensure the formatter does something sensible with whatever it's given, namely show the time when there is one, and not when the field is date only.

I also toyed with the idea of trying to parse the pattern and omit the time elements, but that quickly got too complicated and error prone.

But I appreciate that's not how core works and it makes the structure more complicated, so open to better suggestions :)

Trying to reuse the exact same format for totally different date field types seems like the problem. And that's true of core, too, not just these compact date ranges.

Agreed, but the difficulty comes with not being able to say "this is a format for date/times" and "this is a date only format".

Encourage sites to create multiple formats if they have a mix of date-only and date-time fields to deal with.

Perhaps the module should ship with two default config entities to encourage this. "Medium" by itself doesn't help.

We certainly *could* add a selector on the format entities that ties them to date vs. datetime field types, then force the right thing when configuring the formatter.

But I don't think that's necessary, or even a good move. Given #3021557: Make date_all_day a set of widgets and formatters for core's datetime_range field type and use-cases like @ndlarge there are obviously cases where you want a "Date-only" format to apply to a datetime field.

Frankly, I don't think we can or should go too out of our way to attempt to force site builders to configure this as we expect. If they re-use a format with times in it on a date-only field, they'll see it, and can fix it.

As it is, having separate patterns in the same format for date-only and date+time is both insufficiently powerful (since many of us need "same month" or "same year" patterns, even if there are times) and additional complication in the UI, config storage schema, and more.

If #7 is the only reason we can come up with for leaving it the way it is, I think we should move forward with my counter-proposal @ #2834016: Add 'Compact' datetime range formatter which is both simpler and more powerful.

Any further thoughts?

Thanks!
-Derek

The 2.0 release takes the approach described in #4, so I think we can consider this issue fixed.

Thanks everyone for the input.