[wp-trac] [WordPress Trac] #20973: date_i18n() produces invalid output for shorthand formats

[WordPress Trac]

#20973: date_i18n() produces invalid output for shorthand formats
--------------------------+------------------------------
 Reporter:  Rarst         |       Owner:
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Date/Time     |     Version:  3.4
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------------------

Comment (by raubvogel):

 It’s true: the unpatched {{{date_i18n()}}} does not handle escaped
 literals properly. Test
 {{{
 #!php
 // escape test
 var_dump( 'escape test: ' . date_i18n( 'F | \F | \\F | \\\F | \\\\F |
 \\\\\F | \\\\\\F' ) );
 // escape test with PHP’s date()
 var_dump( 'escape test date(): ' . date ( 'F | \F | \\F | \\\F | \\\\F |
 \\\\\F | \\\\\\F' ) );
 }}}
 results in (German localization)
 {{{
 string 'escape test: Oktober | F | F | \October | \October | \F | \F'
 (length=60)
 string 'escape test date(): October | F | F | \October | \October | \F |
 \F' (length=67)
 }}}
 'F' is translated to "Oktober" but '\\\F' is translated to "\October"
 (should be "\Oktober"). Therefore the unpatched {{{date_i18n()}}} has a
 further issue …

 @Rarst: In Your patch
 {{{
 #!php
 $dateformatstring = preg_replace( "/([^\\\])c/", "\\1" . DATE_W3C,
 $dateformatstring );
 $dateformatstring = preg_replace( "/([^\\\])r/", "\\1" . DATE_RFC2822,
 $dateformatstring );
 }}}
 causes wrong escaping too (it is the same regex as in the original
 {{{date_i18n}}}).

--
Ticket URL: <http://core.trac.wordpress.org/ticket/20973#comment:28>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software