#33624 closed defect (bug) (wontfix)
date_i18n do not returns time in GMT even if GMT is set to false
Reported by: | KestutisIT | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.3 |
Component: | Date/Time | Keywords: | 2nd-opinion dev-feedback |
Focuses: | ui | Cc: |
Description (last modified by )
If I take a timestamp '1441018800' and test it on:
http://www.epochconverter.com/
I get this:
GMT: Mon, 31 Aug 2015 11:00:00 GMT Your time zone: Monday, August 31, 2015 2:00:00 PM GMT+3:00 DST
While, in WordPress, the function which suppose to give me a local time by default, of when $GMT=FALSE, is always giving me the same GMT time instead, whatever I do:
date_i18n("H:i:s", 1441029600); // Same 11:00:00 date_i18n("H:i:s", 1441029600, TRUE); // Same 11:00:00 date_i18n("H:i:s", 1441029600, FALSE); // Same 11:00:00
In WordPress settings, I set my time zone to Europe->Vilnius, which is GMT+2:00 usually, and GMT+3:00 now, because of DTS.
I've still not yet upgraded from 4.2.4 to 4.3, but as per bug fixes report I don't see that it is fixed.
Change History (7)
#2
@
9 years ago
Your advice does not solve my problem. I had to write this function on my own. I believe this is a bug in logic then and has to be discussed with seniors of Wordpress. This has to be left open and assigned for action from seniors. This HAS to be changed as I described, because it's an unexpected behavior.
My workaround is bellow:
public function getPrintPickupDate() { // WordPress bug // BAD: return date_i18n(get_option('date_format'), $this->pickupTimestamp); // OK: return date(get_option('date_format'), $this->pickupTimestamp + get_option( 'gmt_offset' ) * 3600); // WordPress bug WorkAround return date_i18n(get_option('date_format'), $this->pickupTimestamp + get_option( 'gmt_offset' ) * 3600, TRUE); }
#4
@
9 years ago
- Keywords 2nd-opinion dev-feedback added; close removed
Your wish is my command.
Someone who has knowledge in this area will probably pop along shortly.
#5
@
7 years ago
The $gmt
argument is essentially broken completely and date_i18n()
is absolutely not designed to output anything other timezone from WP settings.
If you need a localized output with custom time zone you would have to override timezone option on the fly, for example implementation see https://github.com/Rarst/wpdatetime/blob/master/php/WpDateTimeTrait.php#L88-L96
And yes, it's incorrectly documented to accept Unix timestamp as well, while it actually expects "WordPress timestamp" with time zone offset added.
#6
@
5 years ago
- Description modified (diff)
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
The inline documentation for date_i18n()
had been clarified. It's unlikely that behavior will change though, due to backwards compatibility.
I am planning to introduce a new wp_date()
function, operating with real Unix timestamps, but in context of date_i18n()
this isn't actionable. Just the way it works unfortunately.
Thanks for the report, KestutisIT.
The
$gmt
parameter indate_i18n()
only operates if the$unixtimestamp
parameter is boolean false, upon which the$gmt
parameter gets passed to thecurrent_time()
function which returns the current time according to the timezone settings on the General Settings screen.Yes, this is an awful piece of design, and no, I have no idea why it's like this.
You might be interested in using the
get_date_from_gmt()
function instead. Find out how to use it here.