<p>All dates in the control panel are rendered localized as per the logged-in user's &quot;Formatting Locale&quot; user preference, or their &quot;Language&quot; setting if they haven't set a preferred locale.</p>
<p>For users who haven't set a preferred locale <em>or</em> language, Craft will fall back to the locale defined in the <a href="https://craftcms.com/docs/4.x/config/general.html#defaultcplocale" rel="nofollow noreferrer"><code>defaultCpLocale</code> setting</a>.</p>

CC BY-SA 4.0
2023-09-09T07:54:55.283Z
Thanks! I see now that I should use Craft's own `DateTimeHelper::toDateTime($dateString)` instead of `Carbon`, to get a reliable parsing of the input. This does all the heavy-lifting of figuring out the input format and building a `DateTime` object. See `GraphqlController:464` for an example of how Craft applies the same principle.
Matanya
CC BY-SA 4.0
2023-09-08T20:41:22.460Z
2023-09-08T20:41:22.460Z
Mats Mikkel Rummelhoff
<p>In my plugin I have a datetime field defined in the settings template:</p>
<pre><code>{{ forms.dateTimeField({
    label: &quot;Ends at&quot;|t('optimum'),
    instructions: experiment.isNew ?  'Defaults to 30 days from now' : '',
    id: 'endAt',
    name: 'endAt',
    value: experiment.endAt ?? defaultEndAt,
    errors: experiment.getErrors('endAt')
}) }}
</code></pre>
<p>When I use the picker I get a date in <code>mm/dd/yyyy</code> format.
This is then sent to the backend and parsed back to a <code>Carbon</code> instance.</p>
<p>This is what I'm seeing on my end:</p>
<p><a href="https://i.sstatic.net/IDNvg.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/IDNvg.png" alt="enter image description here" /></a></p>
<p>However, it seems that the date format is not consistent across installations.
As you can see in this <a href="https://github.com/matfish2/craft-optimum/issues/2#issuecomment-1711444522" rel="nofollow noreferrer">issue</a>, the user reports that the datepicker populates the date in <code>dd/mm/yyyy</code> format, which breaks the functionality as the backend is expecting <code>mm/dd/yyyy</code> format.</p>
<p>How can I enforce a uniform format?</p>

<plugins><field><datetime>
Control Panel Date Picker: Inconsistent Date Format
# Control Panel Date Picker: Inconsistent Date Format

(Asked by: username_0 on 2023-09-08)

In my plugin I have a datetime field defined in the settings template:
{{ forms.dateTimeField({
    label: "Ends at"|t('optimum'),
    instructions: experiment.isNew ?  'Defaults to 30 days from now' : '',
    id: 'endAt',
    name: 'endAt',
    value: experiment.endAt ?? defaultEndAt,
    errors: experiment.getErrors('endAt')
}) }}

When I use the picker I get a date in mm/dd/yyyy format.
This is then sent to the backend and parsed back to a Carbon instance.
This is what I'm seeing on my end:

However, it seems that the date format is not consistent across installations.
As you can see in this issue, the user reports that the datepicker populates the date in dd/mm/yyyy format, which breaks the functionality as the backend is expecting mm/dd/yyyy format.
How can I enforce a uniform format?

**Tags:** plugins, field, datetime

---

## 1 answers

### Answer by username_1 on 2023-09-08. Score: 2 | Accepted answer

All dates in the control panel are rendered localized as per the logged-in user's "Formatting Locale" user preference, or their "Language" setting if they haven't set a preferred locale.

For users who haven't set a preferred locale *or* language, Craft will fall back to the locale defined in the [`defaultCpLocale` setting](https://craftcms.com/docs/4.x/config/general.html#defaultcplocale).

> **Comments:**
> **username_0**: Thanks! I see now that I should use Craft's own `DateTimeHelper::toDateTime($dateString)` instead of `Carbon`, to get a reliable parsing of the input. This does all the heavy-lifting of figuring out the input format and building a `DateTime` object. See `GraphqlController:464` for an example of how Craft applies the same principle.  

---

