WordPress.org

Make WordPress Core

Opened 20 months ago

Closed 20 months ago

Last modified 20 months ago

#48858 closed defect (bug) (invalid)

Incorrect UTC time in WP 5.3

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

Description

Hi! For tests I took clean server and clean WordPress install.

For tests all timezones switched to UTC (+0)

CT-20662-bash-4.2# timedatectl
Local time: Mon 2019-12-02 07:35:33 GMT
Universal time: Mon 2019-12-02 07:35:33 UTC

————————

CT-20662-bash-4.2# plesk db ‘SELECT CURRENT_TIME();
+—————-+
| CURRENT_TIME() |
+—————-+
| 07:35:54 |
+—————-+

————————

CT-20662-bash-4.2# /opt/plesk/php/7.3/bin/php -c /var/www/vhosts/system/vpstovdc.host4g.ru/etc/php.ini -r ‘echo date(«h:i:s»);’
07:36:13

In WP also choosed Timezone “London”. Saved.

Universal time is 02.12.2019 10:38:36. Local time is 02.12.2019 07:38:36.

I don’t know why, but Universal time show UTC+3. Have no idea where WP take it.

Ok.
I go to file wp-admin/options-general.php and add add at the beginning:

echo date(«h:i:s»);
die;

https://vpstovdc.host4g.ru/wp-admin/options-general.php show 07:41:49

But if I add it (echo date) after "require_once( dirname( FILE ) . ‘/admin.php’ );"

Then i get 10:42:33


Virtual Private Server with CentOS Linux release 7.6.1810 (Core), PHP 7.3

Change History (18)

#1 @wpamitkumar
20 months ago

  • Component changed from General to Date/Time

#2 follow-up: @wpgurudev
20 months ago

I cannot reproduce the issue as per your given steps. Please refer screenshot attached https://www.imgonline.com.ua/result_img/imgonline-com-ua-twotoone-5ml8oz6YwCpUTP.jpg

Could you please confirm if any other plugin or theme is activated on your install?

#3 in reply to: ↑ 2 @balykin95
20 months ago

Replying to wpgurudev:

I cannot reproduce the issue as per your given steps. Please refer screenshot attached https://www.imgonline.com.ua/result_img/imgonline-com-ua-twotoone-5ml8oz6YwCpUTP.jpg

Could you please confirm if any other plugin or theme is activated on your install?

Sorry, but i didn't see screenshot with Error "ENG: Error 404. Page not found. After processing all images are stored no more than 2 hours"

I can provide you access to admin panel of test site, and, if you need - root access to the server.
But i guaranty, that is a clean install with no themes and plugins:
http://joxi.ru/gmv5ePgUqp86Pr
http://joxi.ru/52aLQjYHE6BLgm

#4 follow-up: @Rarst
20 months ago

Could you please check what does date_default_timezone_get() returns at that point? It must be set to UTC in WP environment, which core does during load.

I am not sure why would it be off in clean core environment, but it's mostly likely reason for date() to be off (if your server clock is verified to be correct).

#5 in reply to: ↑ 4 @balykin95
20 months ago

Replying to Rarst:

Could you please check what does date_default_timezone_get() returns at that point? It must be set to UTC in WP environment, which core does during load.

I am not sure why would it be off in clean core environment, but it's mostly likely reason for date() to be off (if your server clock is verified to be correct).

If i add

echo date("h:i:s ");
echo date_default_timezone_get();
die;

before "require_once( dirname( FILE ) . '/admin.php' );" then I get:

10:25:42 Europe/London

If I place it after "require_once( dirname( FILE ) . '/admin.php' );" then:

01:26:24 UTC

server time for now:

CT-20662-bash-4.2# timedatectl
      Local time: Tue 2019-12-03 10:26:42 GMT
  Universal time: Tue 2019-12-03 10:26:42 UTC
        RTC time: n/a
       Time zone: Europe/London (GMT, +0000)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2019-10-27 01:59:59 BST
                  Sun 2019-10-27 01:00:00 GMT
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2020-03-29 00:59:59 GMT
                  Sun 2020-03-29 02:00:00 BST

#6 @Rarst
20 months ago

Ok, so that 01 is 13 hours I am guessing (h vs H hour format) and UTC time still seems to be 3 hours ahead of London time. This is a really strange one.

Let's try dumping everything at once, please:

var_dump(
        'time(): ' . time(),
        'timezone_string: ' . get_option( 'timezone_string' ),
        'gmt_offset: ' . get_option( 'gmt_offset' ),
        'date_default_timezone_get(): ' . date_default_timezone_get(),
        'date(): ' . date( DATE_RFC3339 ),
        'gmdate(): ' . gmdate( DATE_RFC3339 ),
        'date_i18n(): ' . date_i18n( DATE_RFC3339 ),
        'wp_date(): ' . wp_date( DATE_RFC3339 ),
);

#7 @balykin95
20 months ago

string(18) "time(): 1575371729"
string(17) "timezone_string: "
string(13) "gmt_offset: 1"
string(32) "date_default_timezone_get(): UTC"
string(33) "date(): 2019-12-03T14:15:29+03:00"
string(35) "gmdate(): 2019-12-03T11:15:29+00:00"
string(38) "date_i18n(): 2019-12-03T12:15:29+01:00"
string(36) "wp_date(): 2019-12-03T12:15:29+01:00"

#8 @wpgurudev
20 months ago

Your GMT offset value seems to be 1

#9 @Rarst
20 months ago

Do you still have WordPress set to London? That doesn't look consistent with that.

Also I am stumped why date() is in +03:00 with UTC time zone. Unless I am missing something, that just should not happen on PHP level.

WordPress functions output seems correct and consistent with those settings to me.

This ticket was mentioned in Slack in #core-datetime by rarst. View the logs.


20 months ago

#11 @balykin95
20 months ago

Oh, sry, I edited timezone to UTC+1 in WP for tests. Now I returned it to London
http://joxi.ru/GrqJePgH41JqWm

Output of var_dump in readable form:

string(18) "time(): 1575373900" 
string(30) "timezone_string: Europe/London" 
string(13) "gmt_offset: 0" 
string(32) "date_default_timezone_get(): UTC" 
string(33) "date(): 2019-12-03T14:51:40+03:00" 
string(35) "gmdate(): 2019-12-03T11:51:40+00:00" 
string(38) "date_i18n(): 2019-12-03T11:51:40+00:00" 
string(36) "wp_date(): 2019-12-03T11:51:40+00:00"
Last edited 20 months ago by balykin95 (previous) (diff)

#12 @balykin95
20 months ago

So yeah, that's an initial problem.
After WP include admin.php - date shows Universal time as UTC+3.

Now i add writed below code before include admin.php:

var_dump(
        'time(): ' . time(),
        'date_default_timezone_get(): ' . date_default_timezone_get(),
        'date(): ' . date( DATE_RFC3339 ),
        'gmdate(): ' . gmdate( DATE_RFC3339 ),
);
die;

Output

string(18) "time(): 1575374286" 
string(42) "date_default_timezone_get(): Europe/London" 
string(33) "date(): 2019-12-03T11:58:06+00:00" 
string(35) "gmdate(): 2019-12-03T11:58:06+00:00"

If I add it after include admin.php:

string(18) "time(): 1575374433" 
string(32) "date_default_timezone_get(): UTC" 
string(33) "date(): 2019-12-03T15:00:33+03:00" 
string(35) "gmdate(): 2019-12-03T12:00:33+00:00"
Last edited 20 months ago by balykin95 (previous) (diff)

#13 @Rarst
20 months ago

Again, date() looks "wrong", date_i18n() looks right, but date_i18n() is what used to output that "Universal time" in settings, which looks wrong.

Let's add some more things:

var_dump(
        'time(): ' . time(),
        'current_time( \'timestamp\' ): ' . current_time( 'timestamp' ),
        'current_time( \'timestamp\', true ): ' . current_time( 'timestamp', true ),
        'timezone_string: ' . get_option( 'timezone_string' ),
        'gmt_offset: ' . get_option( 'gmt_offset' ),
        'date_default_timezone_get(): ' . date_default_timezone_get(),
        'date(): ' . date( DATE_RFC3339 ),
        'gmdate(): ' . gmdate( DATE_RFC3339 ),
        'date_i18n(): ' . date_i18n( DATE_RFC3339 ),
        'date_i18n() / GMT: ' . date_i18n( DATE_RFC3339, false, true ),
        'wp_date(): ' . wp_date( DATE_RFC3339 ),
);

This might be something wrong with your PHP install, possibly borked timezone database in it or something.

#14 @balykin95
20 months ago

Output of new var_dump (after include admin.php):

string(18) "time(): 1575375722" 
string(39) "current_time( 'timestamp' ): 1575375722" 
string(45) "current_time( 'timestamp', true ): 1575375722" 
string(30) "timezone_string: Europe/London" 
string(13) "gmt_offset: 0" 
string(32) "date_default_timezone_get(): UTC" 
string(33) "date(): 2019-12-03T15:22:02+03:00" 
string(35) "gmdate(): 2019-12-03T12:22:02+00:00" 
string(38) "date_i18n(): 2019-12-03T12:22:02+00:00" 
string(44) "date_i18n() / GMT: 2019-12-03T15:22:02+03:00" 
string(36) "wp_date(): 2019-12-03T12:22:02+00:00"

#15 follow-up: @Rarst
20 months ago

Oookay, I think I see a code path that breaks for you there (date_i18n() with GMT flag).

Let's try this please:

var_dump(
        'date_i18n() / GMT: ' . date_i18n( DATE_RFC3339, false, true ),
        'wp_date() / UTC: ' . wp_date( DATE_RFC3339, null, new DateTimeZone( 'UTC' ) ),
        'UTC offset: ' . ( new DateTimeZone( 'UTC' ) )->getOffset( new DateTime( 'now' ) ),
        'date_create() / default: ' . date_create( '@' . time() )->format( DATE_RFC3339 ),
        'date_create() / UTC: ' . date_create( '@' . time() )->setTimezone( new DateTimeZone( 'UTC' ) )->format( DATE_RFC3339 )
);

#16 in reply to: ↑ 15 @balykin95
20 months ago

Replying to Rarst:

Oookay, I think I see a code path that breaks for you there (date_i18n() with GMT flag).

Let's try this please:

Output of new var_dump

string(44) "date_i18n() / GMT: 2019-12-03T16:17:07+03:00" 
string(42) "wp_date() / UTC: 2019-12-03T16:17:07+03:00" 
string(17) "UTC offset: 10800" 
string(50) "date_create() / default: 2019-12-03T13:17:07+00:00" 
string(46) "date_create() / UTC: 2019-12-03T16:17:07+03:00"

#17 @Rarst
20 months ago

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

Yeah, that offset should be 0. Your PHP instance thinks UTC is offset from UTC by 3 hours, so something is quite broken with it, likely with bundled time zone database.

Nothing WordPress core can do here, there is no way to proof against upstream language giving incorrect value.

#18 @balykin95
20 months ago

Maybe it will help to somebody.
Problem was resolved with

yum update tzdata

Thanks for help in diaagnosing.

Note: See TracTickets for help on using tickets.