Make WordPress Core

Opened 3 years ago

Last modified 3 months ago

#33624 new defect (bug)

date_i18n do not returns time in GMT even if GMT is set to false

Reported by: KestutisIT Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.3
Component: Date/Time Keywords: 2nd-opinion dev-feedback
Focuses: ui Cc:


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 (5)

#1 @johnbillion
3 years ago

  • Keywords close added

Thanks for the report, KestutisIT.

The $gmt parameter in date_i18n() only operates if the $unixtimestamp parameter is boolean false, upon which the $gmt parameter gets passed to the current_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.

#2 @KestutisIT
3 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 @atomicjack
3 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 @Rarst
3 months 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.

Note: See TracTickets for help on using tickets.