Date Formats

[jasonvarga]

While working on a bunch of date fixes in https://github.com/statamic/cms/pull/3730 we thought... Why do people use the date_format setting?

My thinking is that by default we use American dates, and people just wanted a way to display it in their own country's format. Back in the v1 days, when this setting was introduced, we didn't have a good way to localize dates so we just gave you control over the format.

But now, localization is well supported in both Carbon (for the PHP side) and Moment (for the JS side).

We had the idea to get rid of the date_format setting completely, and instead just leverage the libraries' localization features.

If your locale is set to en, you'll see dates in the American format.

• 19/05/2021
• 19 May 2021 6:36 PM

If it's de, you'll see the German format

• 19.05.2021
• 19. Mai 2021 18:37

...and so on.

My question is, does anyone use the date_format setting to customize the format for a reason other than localization. i.e. Would you miss the ability to customize the format if it was removed?

[j3ll3yfi5h]

Never used it for something else...

Other question: how do you handle this in templates?

Is this the way to go?

{{ locales }}
    {{ if first }}
        {{ if locale:short == 'de' }}
            {{ date format_localized='%e. %B %Y' }}
        {{ elseif locale:short == 'en' }}
            {{ date format_localized='%e %B %Y' }}
        {{ /if }}
    {{ /if }}
{{ /locales }}

[aerni]

@j3ll3yfi5h Use the iso_format modifier: https://statamic.dev/modifiers/iso_format#content.

[wesort]

I support leaning into locales.

However, UK is en and that date format isn't locally correct. Does en_uk or en_gb exist?

Also, maybe ISO date format be the default? ie: 2021-05-19

I would still need the format modifier for templating, but I presume that's a separate concern?

[jonassiewertsen]

In the control panel itself I only used the date_format to localize dates.

[aerni]

@jasonvarga I like the idea to use the locales as the base. As long as local differences are considered like @wesort mentioned. And a way to change how the date is displayed in certain scenarios would be great. Like in date fieldtypes.

[jasonvarga]

@wesort It would handle locales, not just languages. So it would know the difference between en-GB, en-US, and en-AU, for example. Instead of you just specifying en, you'd configure en-GB

[afonic]

To be honest the only use case I could find is that a user wants to use the backend in English but see dates in the Greek format.

[jasonvarga]

@aerni

And a way to change how the date is displayed in certain scenarios would be great. Like in date fieldtypes.

I know this remark is stemming from statamic/cms#3516 That issue is more like... "It should have time in it, but doesn't." Do you really need to customize the format? Or are you just wanting to make sure the time is displayed?

[vitor-ao]

I use {{ date format_localized="%d \d\e %B" }} because of the month names. My locale is pt.

[jasonvarga]

We wouldn't be removing any modifiers. You'll still be able to do {{ date | format:... }} or | format_localized or | iso_format, etc.

This is really just focusing on the date_format in config/statamic/system.php and config/statamic/cp.php.

[dannyuk1982]

There isn't really a standard date in the UK, it's usally client preference, some like DD.MM.YYYY some DD.MM.YY, some those with / instead of ., some like the Month name etc. so I use format on most sites depending on their preference.

[jacksleight]

I really like the idea of just using the locale to decide the date format, but the control panel would need to work with locales that include a country. Last time I tried that it broke some of the text. See https://github.com/statamic/cms/issues/3265#issuecomment-802142417.

If that’s no longer an issue (or can be fixed) then using the locale sounds like the perfect solution.

[jasonvarga]

There isn't really a standard date in the UK, it's usally client preference

This feels like a little bit of an edge case. 🤔 As long as it goes day/month/year, someone in the uk should be fine, right? 2 digit years, or slash vs. dot is a small thing. It's just that if they're stuck with an American date that you'd have an issue because it goes month/day/year.

[dannyuk1982]

There isn't really a standard date in the UK, it's usally client preference

This feels like a little bit of an edge case. 🤔 As long as it goes day/month/year, someone in the uk should be fine, right? 2 digit years, or slash vs. dot is a small thing. It's just that if they're stuck with an American date that you'd have an issue because it goes month/day/year.

Sorry, are we just talking CP? If so then just having the right day/month/year order would be fine. If the frontend website then absolutely clients always want different formats.

[lukeagsmith]

ISO as a default with a locale override would work for me.

[jasonvarga]

@dannyuk1982

If the frontend website then absolutely clients always want different formats.

You can always do {{ date | format:however }}, but I can see how having {{ date }} output in the format of your choice without a manual modifier is useful. 👍 That's basically the only thing the date_format in system.php is controlling at the moment.

@lukeagsmith

ISO as a default with a locale override would work for me.

Can you explain what you mean by locale override?

[lukeagsmith]

I was assuming a date_format setting:

• date_format='' gets you ISO
• date_format='en-GB' gets you dd-mm-yyyy.

But I guess if you used the CP locale there would be no need for a date_format setting at all?

[jasonvarga]

The proposal is to remove date_format completely. We'd just give you a date format appropriate to your CP/user's locale.

[brendanfalkowski]

@jasonvarga Going to locale-only would be annoying personally. In every Statamic project, I actually do change config/statamic/cp.php to use 'date_format' => 'Y-m-d' (ISO style). This makes looking at date-based indexes much nicer in the control panel and it should match the Statamic filesystem (no context switching mentally).

I would bet a lot of programmers and especially those working across borders have sworn off their native country's way of writing dates and prefer the sort-friendly ISO format for everything in their life. I definitely have adopted it.

If it has to go locale-first, I'd appreciate the option to declare ISO mode.

[jasonvarga]

@brendanfalkowski That's fair. 🤔

I think being able to select between "localized" and "ISO-ish" formats would probably be easier to maintain than letting you type in absolutely any format like how it currently works.

[aerni]

@jasonvarga

And a way to change how the date is displayed in certain scenarios would be great. Like in date fieldtypes.

I know this remark is stemming from statamic/cms#3516 That issue is more like... "It should have time in it, but doesn't." Do you really need to customize the format? Or are you just wanting to make sure the time is displayed?

Sometimes it makes sense to display the date like 19.05.2021 and sometimes like 19. Mai 2021.

In your initial comment you said:

If your locale is set to en, you'll see dates in the American format.

19/05/2021 19 May 2021 6:36 PM If it's de, you'll see the German format

19.05.2021 19. Mai 2021 18:37 ...and so on.

So I assume the display format is somehow configurable within a locale?

[stephenmeehanuk]

This is great. Yes, if the date picker field could mirror the locale setting that'd be a neat touch. I'm based in the UK, I'd prefer to see the date picker display the date as DD/MM/YYYY instead of MM/DD/YYYY

I'm happy to format the date on the frontend using modifiers.

In a multi language site, could the date picker field auto update based on the language being viewed?

[jasonvarga]

@aerni

Sometimes it makes sense to display the date like 19.05.2021 and sometimes like 19. Mai 2021.

I whipped up this table to help clear things up.

By scrapping a specific sitewide "format" config, and instead just basing it off of a locale, we're able to use the appropriate format where necessary for the UI.

If the UI needs a small date, like in the date picker, we'll reach for $date->format('L'). A longer headline? Maybe LL. Just time? LT.

It'll automatically use appropriate localized conventions (order of month/day/year, slashes vs dots), translate days and months with appropriate casing (Thursday/Donnerstag/jeudi), etc.

[aerni]

That table is helpful. Will we be able to configure the way it shows in the UI?

[jasonvarga]

No it wouldn't be configurable.

We'd pick the format that makes sense for whatever UI element it's being used in.

Like I said:

If the UI needs a small date, like in the date picker, we'll reach for $date->format('L'). A longer headline? Maybe LL. Just time? LT.

[aerni]

Ah, I understand now. I think that would be fine with me. There's probably only a handful of cases where a custom format could be nice.

[aerni]

Did you also consider time zones for the display date? You could define both a user's locale and time zone in the preferences key in the user yaml.

[jasonvarga]

Timezones are a separate can of worms. This issue is just talking about formatting.

[aerni]

We love worms though 🤪