#49120 closed defect (bug) (duplicate)
strtotime() in WP::send_headers()
Reported by: | autotutorial | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Date/Time | Keywords: | |
Focuses: | Cc: |
Description
https://developer.wordpress.org/reference/classes/wp/send_headers/ bug strtotime function. From WordPress 5.3 use class DateTime.
Change History (9)
#1
@
5 years ago
- Component changed from General to Date/Time
- Keywords reporter-feedback added
- Summary changed from Offser to strtotime() in WP::send_headers()
#2
@
5 years ago
Hi thanks for your welcome.
It is a logical bug that does not reflect the current WordPress 5.3 wp_date coding and other related functions do not use functions dependent on the current offset (all old php functions use the current offset except gmdate, gmmktime for it is 0).
Before WordPress 5.3 it was used current_time with strtotime or date but it created problems for this it has been replaced by wp_date, current_datetime (DateTime class).
An example of code follows, I was unable to create the bug but it would be nice to use the same code for each context.
<?php //Bad old function with offset $date = '2020-02-01 00:00'; //plugin date_default_timezone_set('Australia/Adelaide'); //ini_set( 'date.timezone', 'Australia/Adelaide'); $timestamp[] = strtotime( $date ); $offset = date( "Z" ); $value = current( $timestamp ); //Always UTC $timestamp[] = $value + $offset; //WordPress core #maybe date_default_timezone_set('UTC'); $timestamp[] = strtotime( $date ); var_dump( $timestamp );
#3
@
5 years ago
- Keywords reporter-feedback removed
- Milestone Awaiting Review deleted
- Resolution set to duplicate
- Status changed from new to closed
Duplicate of #48935.
#4
@
5 years ago
@SergeyBiryukov @Rarst happy New Year
is there the concept of time for code executed inside the WordPress core and outside the WordPress core? I explain in mysql only DATETIME table uses UTC or as of MySQL 8.0.19, you can specify a time zone offset (other than a negative offset equal to zero -00:00) when inserting TIMESTAMP and DATETIME values into a table while other functions could use a non-zero offset. it would be nice to add a comment to wpdb class.
MySQL DATETIME prior 5.6.5 https://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html
MySQL DATETIME after https://dev.mysql.com/doc/refman/8.0/en/datetime.html
#5
@
5 years ago
I don't follow what you mean by inside/outside distinction. The time is always the same. Any differences are just how is it expressed (e.g. human-readable string in a time zone, Unix timestamp, WP timestamp summed with a time zone offset, etc).
#6
@
5 years ago
sorry my bad english, I updated the previous message .. Currently there is no link between the time of the php server and the mysql server.
In short, this is the problem
#7
@
5 years ago
WordPress does not use any time zone offsets when operating its MySQL database. I am not sure why would it need to be pointed out specifically.
#8
@
5 years ago
I know WordPress only executes the code but the comment is used to create good coding.
For example, the plug-in programmer may decide to set a time zone other than UTC but wordpress core expects only UTC.
An example follows.
<?php date_default_timezone_set('Europe/London'); $wpdb->time_zone = 'Europe/London';
#9
@
5 years ago
Please fix strtotime https://github.com/WordPress/WordPress/blob/master/wp-includes/rest-api.php#L966
Hi there, welcome back to WordPress Trac!
Could you clarify what exactly is the bug here, and how to reproduce it on a clean install?
As far as I can see, this code works as intended, and there are more than 70 other instances of
strtotime()
in WordPress core.