Make WordPress Core

Opened 9 years ago

Closed 5 years ago

Last modified 4 years ago

#33624 closed defect (bug) (wontfix)

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

Reported by: kestutisit's profile 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 Rarst)

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)

#1 @johnbillion
9 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
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 @atomicjack
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 @Rarst
6 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 @Rarst
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.

Note: See TracTickets for help on using tickets.