Make WordPress Core

Opened 5 years ago

Closed 3 years ago

Last modified 2 months ago

#23056 closed defect (bug) (invalid)

date_i18n() does not localize dateformat 'r'

Reported by: jrf Owned by:
Milestone: Priority: normal
Severity: normal Version: 1.5
Component: I18N Keywords: needs-patch
Focuses: Cc:


The weekday and month strings in a date being formatted with the 'r' format character are not being localized.

I've looked at the trunk code and it looks like the 'r' case is not being considered at all in the date_i18n() function.

This bug is very easy to reproduce:

print ( date_i18n( 'r', 972144067 ) );

Expected output for language Dutch:
za, 21 okt 2000 16:01:07 +0200

Received output:
Sat, 21 Oct 2000 16:01:07 +0000

Potential patch:

A bit of a hacky patch would go along the lines of:

if( !function_exists( 'patch_date_i18n' ) ) :
add_filter( 'date_i18n', 'patch_date_i18n', 10, 4 );
function patch_date_i18n( $formatted_date, $req_format, $timestamp, $gmt ) {

	if( $req_format !== 'r' )
		return $formatted_date;

	global $wp_locale;
	$datefunc = $gmt? 'gmdate' : 'date';

	$find = array (
		$datefunc( 'M', $timestamp ),
		$datefunc( 'D', $timestamp ),
	$replace = array(
		$wp_locale->get_month_abbrev( $wp_locale->get_month( $datefunc( 'm', $timestamp ) ) ),
		$wp_locale->get_weekday_abbrev( $wp_locale->get_weekday( $datefunc( 'w', $timestamp ) ) ),
	return str_replace( $find, $replace, $formatted_date );

Hope this helps. Would be great if this could be fixed.

Smile, Juliette

Change History (8)

#1 @jrf
5 years ago

  • Cc trac.wordpress.org@… added

#2 @SergeyBiryukov
5 years ago

  • Keywords has-patch removed
  • Version changed from trunk to 1.5

#3 @dd32
5 years ago

This is probably a case where it shouldn't be translated IMO

The 'r' date format is not intended for human consumption, rather it's a RFC 2822 date format for usage in inter-computer communications (originally email), such a format does not work when translated.

#4 @dd32
5 years ago

The other side of the argument of course is that date_i18n() is designed for user-facing timestamps rather than computer-facing ones.

#5 @jrf
5 years ago

@dd32 I had exactly the same thoughts ;-). Both points are valid, but considering that date_i18n() is meant for localization and using it would be a conscious choice of a programmer, I believe the second argument holds most water. (Which is of course why I reported it ;-) )

#6 @chriscct7
3 years ago

  • Keywords needs-patch added

#7 @johnbillion
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

The r format is specifically for the RFC 2822 date format. It should not be localised.

#8 @Rarst
2 months ago

More broad issue about broken shorthand formats: #20973

On localization specifically I would argue it's not a purpose of date_i18n() to recognize specific format and intention behind it. What if someone supplies RFC822 in the "raw" form as D, d M y H:i:s O ? Their intent might be to get RFC822 output, with lack of localization implicit in it, but there is no way for implementing function to know.

I would say date_i18n() is meant to localize any input. If result without localization is desired then date() should be used instead of it.

Note: See TracTickets for help on using tickets.