Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#48733 closed defect (bug) (invalid)

Problems with date after replacing date_i18n() with wp_date()

Reported by: Guido07111975 Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.3
Component: Date/Time Keywords:
Focuses: Cc:



I'm the author of an events plugin and have updated my plugin with the newly core function wp_date(). I simply replaced all occurences of date_i18n() with wp_date(). That's it. Example:

wp_date( $dateformat, esc_attr( $date ) )

FYI, this format is being saved in database (date, without time): 1574121600

I'm getting complaints from (some) users about offsett, the previous day is being returned after saving the event. When rolling back to date_i18n() everything is being returned properly again.

Change History (4)

#1 @Rarst
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Please note `wp_date()` documentation:

Note that, unlike date_i18n(), this function accepts a true Unix timestamp, not summed with timezone offset.

If you are passing WP timestamp (a sum of Unix timestamp and time zone offset) to it then it won't produce correct result.

Dev note for the component changes has some more details.

#2 @Guido07111975
2 years ago


Don't get it, sorry. My example 1574121600 is a Unix timestamp, and without offset.. Am I right?
So I store a valid value in database and retrieve it again without offset.

Or perhaps I should open a thread at support forum?


I might get it, is the third argument $timezone of wp_date() causing this "previous day issue" in some cases?

Last edited 2 years ago by Guido07111975 (previous) (diff)

#3 @Rarst
2 years ago

My example 1574121600 is a Unix timestamp, and without offset.. Am I right?

If that timestamp produces the expected result with date_i18n() but not wp_date() then no, you are wrong and that is in fact a WP timestamp, not Unix one.

I know this is horribly confusing, but date_i18n() had never worked with Unix timestamps and big part of wp_date() role is to move away from the horror of WP timestamps.

Here is a quick way to illustrate with code:


        // this will be correct
        wp_date( DATE_RFC3339, time() ),

        // this will be wrong
        date_i18n( DATE_RFC3339, time() ),

        // this will be correct
        date_i18n( DATE_RFC3339, time() + ( HOUR_IN_SECONDS * get_option( 'gmt_offset' ) ) ),

#4 @Guido07111975
2 years ago


Thanks for your response.

Meanwhile I created a thread at support forum:

And solved my problem by adding the timezone as third parameter:

$zone = new DateTimeZone('UTC');
wp_date( $dateformat, esc_attr( $date ), $zone )


Note: See TracTickets for help on using tickets.