#37634 closed defect (bug) (fixed)
Wrong usage of $gmt parameter in date_i18n() in options-general.php
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.7 | Priority: | normal |
Severity: | normal | Version: | 3.1 |
Component: | Administration | Keywords: | good-first-bug has-patch |
Focuses: | Cc: |
Description
For showing the universal time on the "General Settings" screen, the following code is used:
date_i18n( $timezone_format, false, 'gmt' )
However, the third parameter, $gmt
is actually a boolean has been that way ever since 0.71.
It should therefore look like this:
date_i18n( $timezone_format, false, true )
It currently only works because of this line in date_i18n
, where gmt
is implicitly true
and thus gmdate
is used:
$datefunc = $gmt? 'gmdate' : 'date';
Introduced in [9616].
Attachments (1)
Change History (8)
#2
@
8 years ago
Note that the $gmt
parameter is still needed for these lines in date_i18n()
:
<?php if ( false === $i ) { if ( ! $gmt ) $i = current_time( 'timestamp' ); else $i = time(); // we should not let date() interfere with our // specially computed timestamp $gmt = true; }
However, they could be simplified to just:
<?php if ( false === $i ) { $i = current_time( 'timestamp', $gmt ); }
I guess maybe we'll want to open a separate ticket for that though.
#3
follow-up:
↓ 7
@
8 years ago
Feel free to open a new ticket for that :-) Such a change would need lots of tests beforehand though.
Simplifying date_i18n
would probably also help for #18146.
#4
@
8 years ago
- Keywords has-patch added; needs-patch removed
Attached a patch that fixes the last parameter.
Actually, there is no difference between
date()
andgmdate()
in WordPress, so that line can be removed. At the time WordPress was experimenting with setting the default PHP time based on the site's timezone, but in the end it was decided to just always have the default timezome be UTC/GMT. Which means thatdate()
andtime()
always return UTC values, and thus usinggmdate()
is unnecessary. (I discovered this just the other day when I was researching a date/time-related bug in a plugin.) See #9588 and [12727].I'd suggest that every reference to
gmdate()
in core be changed todate()
to avoid this confusion.