date_i18n and timestamps

  • swedish boy

    (@swedish-boy)


    10 years, 6 months ago

    This was a bit puzzling to me, but date_i18n doesn’t adjust to local timezone as one would think. If you set your timezone in wp-admin to GMT+1 this is what happens in the following 2 examples.

    Let’s say GMT time is 17:05.

    echo date_i18n('H:i');

// Will output current hours and minutes of local timezone
//Result: 18:05

    However if you give this function a custom timestamp or time():

    echo date_i18n('H:i', time());
// Output: 17:05

// $some_timestamp is set to time()-3600;
echo date_i18n('H:i', $some_timestamp);
// Output: 16:05

    In both last examples date_i18n outputs GMT time.

    The fix is to do add the following to your timestamp:

    $timestamp += get_option( 'gmt_offset' ) * 3600;
echo date_i18n('H:i', $timestamp );

    Almost a bug if you ask me.

Viewing 7 replies - 1 through 7 (of 7 total)
  • Moderator bcworkz

    (@bcworkz)

    10 years, 6 months ago

    time() always returns GMT time, so date_i18n() is simply translating the data you gave it into your local format. When you don’t provide any data, it uses current_time('timestamp') to get local time, not time() for GMT. If you do not feed it equivalent data, you cannot expect equivalent output. From the Codex page on current_time():

    current_time( ‘timestamp’ ) should be used in lieu of time() to return the blog’s local time. In WordPress, PHP’s time() will always return UTC

    Thread Starter swedish boy

    (@swedish-boy)

    10 years, 6 months ago

    Yes. You’re right.

    But it’s good to point out how it works for others who might expect it to translate time and date to given timezone. (Since it does this when you don’t feed it a custom timestamp).

    I also don’t understand the last flag you can pass to date_i18n, boolean whether to convert to GMT or not?

    I also don’t really see the point of date_i18n function over PHP’s strftime() if you have the right PHP-locale installed?

    Moderator bcworkz

    (@bcworkz)

    10 years, 6 months ago

    The last flag indeed does not make sense if you are supplying a GMT timestamp, but if the timestamp is for a particular time zone, the flag can be useful in some situations where it’s preferable to have all time references be in a single timezone. I don’t know about you, but comparing times from a variety of timezones makes my head hurt! I prefer everything to be GMT, then I don’t have to even think about it.

    Yes, there is little point in date_i18n() over strftime() IF the right locale is installed. But it is not always installed right. WP maintains it’s own locale information and only date_i18n() knows how to use it. strftime() has no way to access WP locale information, so if the PHP locale is not right, it will fail whereas date_i18n() typically would not.

    John Blackbourn

    (@johnbillion)

    WordPress Core Developer

    10 years, 6 months ago

    This is a confusing situation currently, and I’ve been thinking of ways that WordPress can improve this.

    As you correctly noted, date_i18n() formats a date according to the locale. It doesn’t adjust the date to the selected timezone.

    Here’s how to output a date adjusted according to the selected timezone: http://wordpress.stackexchange.com/questions/94755/converting-timestamps-to-local-time-with-date-l18n/107258#107258

    Thread Starter swedish boy

    (@swedish-boy)

    10 years, 5 months ago

    Thanks John for the tip.

    The function to use is get_date_from_gmt() then.

    a_ludi

    (@a_ludi)

    10 years, 1 month ago

    Some time has gone by, but the problem persists. In my opinion the current situation is quite ugly, e.g.

    date_i18n($format, get_date_from_gmt($dateTime->format('Y-m-d H:i:s'), 'U'));

    That is three formatting conversions effectively realizing only one. This is not only badly readable but also time-consuming.

    My proposal is to add another parameters to date_i18n which selects the timezone.

    Moderator bcworkz

    (@bcworkz)

    10 years, 1 month ago

    My proposal is to add another parameters to date_i18n which selects the timezone.

    That’s a good idea, but it will do little good suggesting it here. First discuss the idea here (reference this topic), and if the consensus is favorable, create a trac ticket for a feature request. The request may get implemented faster if you are able to provide a code patch with your ticket.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘date_i18n and timestamps’ is closed to new replies.