Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#48733 closed defect (bug) (invalid)

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

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

Description

Hi,

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
6 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
6 years ago

Hi,

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?

Guido

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

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

#3 @Rarst
6 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:

<?php

var_dump(
        // 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
6 years ago

Hi,

Thanks for your response.

Meanwhile I created a thread at support forum:
https://wordpress.org/support/topic/problems-with-timezone-when-using-new-function-wp_date

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

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

Guido

Note: See TracTickets for help on using tickets.