Format ignored for datetime widget when date and time format specified

[EthanLMartin]

Describe the bug
When using the date time widget, if the date_format or time_format options are used, then the format option is ignored.

The documentation specifies that "If set, date_format and time_format are not used."

To Reproduce

1. Create a widget using the datetime widget
2. Add the format, date_format and time_format options (e.g. YYYY-MM-DDTHH:mm:ss, DD/MM/YYYY and HH:mm respectively)
3. When publishing the content, the format is ignored and is saved as {date_format}T{time_format} (e.g. DD/MM/YYYYTHH:mm based on the above)

Expected behavior
As per the documentation, expected the saved format so be the overall format specified. (In the examples above this would be YYYY-MM-DDTHH:mm:ss)

Screenshots
N/A

Applicable Versions:

• Decap CMS version: 3.1.11
• Git provider: GitLab
• OS: All
• Browser version: All
• Node.JS version: 20

CMS configuration

backend:
  name: test-repo
media_folder: static/images
public_folder: /images
collections:
  - label: Cross club
    name: cross-club
    files:
      - name: promotion
        label: ⚙ Promotion
        widget: object
        fields:
          - name: timedPromotions
            label: Timed promotions
            widget: list
            fields:
              - name: promotionDetails
                label: Timed promotion content
                widget: object
                fields:
                  - name: from
                    label: From
                    widget: datetime
                    format: YYYY-MM-DDTHH:mm:ss
                    dateFormat: DD/MM/YYYY
                    timeFormat: HH:mm
                  - name: to
                    label: To
                    widget: datetime
                    format: YYYY-MM-DDTHH:mm:ss
                    dateFormat: DD/MM/YYYY
                    timeFormat: HH:mm
            hint: ''
            default: []
            collapsed: true
        file: data/cross-club/club/promotion.json

Additional context
N/A

[aOpenbrier]

I'm having this issues as well. Since I'm setting up Decap for the first time I'm not sure if this was a new bug or just incorrectly documented. It doesn't seem that any of formatting properties work according to the documentation:

• format:
  • "If set, date_format and time_format are not used." — per this issue, not working
• time_format:
  • "sets time display format in UI;" — picker does not respond to changes, always MM/DD/YYYY
• date_format:
  • "sets date display format in UI;" — picker does not respond to changes, always hh:mm A
  • "If used without time_format, only the date picker is displayed." — This is correct. Time is hidden on picker if date_format is present, though date_format had no other affect.

When I remove all 3 properties the default format is not the correct time (e.g. 2006-01-02T15:04:05.000Z). The Decap default has the "Z" literal purporting to be UTC but the hours were not converted from my local time (-07:00). I would recommend using: format: YYYY-MM-DDTHH:mm:ssZ (2006-01-02T15:04:05-07:00) in Decap config to get the true time in content files.

[adrian5]

I'm seeing the same behavior. Does the UI reflect your date_format if you change it to e.g. DD.MM.YYYY? Here it uses that format for storage but not the UI.

I have all three values set up in NetlifyCMS (Euro-style UI, ISO-like storage), where they seem to coexist without issue. Did I get lucky, or is this a regression? Unfortunate that this widget seems so difficult to get right, as quite a bit of (re)work seems to have gone into it already by the developers.

[martinjagodic]

@EthanLMartin you are correct, the documentation states exactly the opposite of the actual behavior.

the truth is: if date_format or time_format are set, format is ignored.

We have to change either the docs or the implementation. I am leaning towards changing the implementation.

Does anybody have any other proposals on how to approach this?

[martinjagodic]

@EthanLMartin @adrian5 this was addressed in #7261 and released in 3.3.0. Can you test it and let me know if it works for you now?

[adrian5]

@martinjagodic I have just tested this on 3.3.2 and format is now respected if all three are set. My UI issue persists.