Date formatting shortcuts

[iseulde]

Follow-up on #30864. Related to #39222.

The idea is to have a series of translated (and maybe filterable) shortcuts for date strings that are commonly used, which would hopefully encourage more consistent date formats in admin interfaces.

It's similar to what ​Moment.js does, but I think it wouldn't hurt to be a bit more verbose (for clarity).

I'm thinking of something like get_date_format( 'time' ), where there could be a few core defined strings like:

• time: 7:30 p.m.
• short-date: 12/14/2016
• long-date: 14 December 2016
• full-date: Wednesday, 14 December, 2016

Etc.

I think this would also make it a bit easier for translators. :)

Summary from #30864:

Replying to iseulde:

[...] I don't think it would be a bad idea to have a shortcut to use these in core, to make it easier for plugins to pick a date format that is properly localised.

Replying to markjaquith:

[...] We should have, in core, filterable, localized "short" and "long" date/time and date-time format strings that we use in core and that developers can use.

Replying to azaozz:

[...] Thinking we need something like localized_date_time array with short and long date formats, and short and long (with seconds) time formats? That should be settable by translating the default settings.

[pbearne]

Hi

Is this the sort of function you are suggesting?

Do we have a list of formats

<?php
function get_date_format( $format ) {
        $date_string = '';
        switch ( strtolower( $format ) ) {
                case 'time':
                    // Translator: time format
                        $date_string = __( 'G:i' );
                        break;
        // add more format as needed here

                default:
                        $date_string = $format;
                        break;
        }

        return apply_filters( 'get_date_format', $date_string, $format );
}

and add this line into date_i18n() and the_date() functions etc.

<?php
$dateformatstring = get_date_formatted( $dateformatstring );

[Rarst]

I don't quite follow the suggested workflow. Would these formats be core (translatable) constants or options ?

Also this seems like it would be very clunky to write in backwards compatible way if it introduces an new function.

For admin workflows I would think, unless output is meant to be customized by user, it should just be ISO8601 based. Multiple formats multiplied by multiple locales might add up to a complete zoo of formats, with little clarity for developers which is preferable when.

[Rarst]

I went over original ticket again and while it makes sense to me there are too many unknowns for implementation at the moment.

If someone is interested in advancing this, I think spec needs to be worked out, including answering following questions:

1. Which specific formats need to be included in set?
2. Do other languages might need more formats than English available?
3. Does this need to be exposed as settings in interface?
4. Does this need to be exposed as filterable?
5. How does distinction between formats are documented and explained to developers for implementation?

I feel the main challenge here is disconnect between generic label like full-date and intended usage of it and different locales possibly expecting different output for a context.

For example the original post includes day of the week. Is it equally important in all contexts where date might be used? Is date of the week equally common as part of the date across all language? Should the localization include all parts of original format or try to satisfy the semantic context of label?