Overhaul the time functions #227
Comments
Actually no. The transformation used is not elegant in any way (guess it was in a time before PHP My local system runs on CEST (UTC + 2), so (Hour/minute example just for demonstration. If the time matches, the date values are the same either.) Ran a quick verification test on WP test site: die( 'Unix timestamp: ' . time() . '<br>'
. 'String from Unix timestmap: ' . strftime( '%Y-%m-%d %H:%M:%S', time() ) . '<br>'
. 'WP timestamp: ' . current_time( 'timestamp' ) . '<br>'
. 'String from WP timestamp: ' . strftime( '%Y-%m-%d %H:%M:%S', current_time( 'timestamp' ) ) . '<br>'
. 'WP current time: ' . current_time( 'Y-m-d H:i:s' ) );outputs
Assuming we want to stay with local date values in the database, we should simply synchronize the notation here, i.e. use the shorter, non-deprecated and more intuitive |
We use "WP timestamp" in combination with strftime in the tracking routine and retrieve WP Time in "Y-m-d" format for retrieval in the dashboard logic. While it is discouraged to work with "WP Timestamps" and strftime is deprecated as of PHP 8.1, is makes sense to use the same source of time on both ends. The present logic is not inherently wrong. The "WP timestmap" is basically a unix timestamp with zone offeset already calculated and parsing the result yields a local time value shifted to GMT. Zone is not part of the output here, so it's effectively the same as Y-m-d local date. We not use the current time in Y-m-d notation on both ends without breaking or invalidating the present logic.
We use "WP timestamp" in combination with strftime in the tracking routine and retrieve WP Time in "Y-m-d" format for retrieval in the dashboard logic. While it is discouraged to work with "WP Timestamps" and strftime is deprecated as of PHP 8.1, is makes sense to use the same source of time on both ends. The present logic is not inherently wrong. The "WP timestmap" is basically a unix timestamp with zone offeset already calculated and parsing the result yields a local time value shifted to GMT. Zone is not part of the output here, so it's effectively the same as Y-m-d local date. We not use the current time in Y-m-d notation on both ends without breaking or invalidating the present logic.
We use "WP timestamp" in combination with strftime in the tracking routine and retrieve WP Time in "Y-m-d" format for retrieval in the dashboard logic. While it is discouraged to work with "WP Timestamps" and strftime is deprecated as of PHP 8.1, is makes sense to use the same source of time on both ends. The present logic is not inherently wrong. The "WP timestmap" is basically a unix timestamp with zone offeset already calculated and parsing the result yields a local time value shifted to GMT. Zone is not part of the output here, so it's effectively the same as Y-m-d local date. We not use the current time in Y-m-d notation on both ends without breaking or invalidating the present logic.
We use "WP timestamp" in combination with strftime in the tracking routine and retrieve WP Time in "Y-m-d" format for retrieval in the dashboard logic. While it is discouraged to work with "WP Timestamps" and strftime is deprecated as of PHP 8.1, is makes sense to use the same source of time on both ends. The present logic is not inherently wrong. The "WP timestmap" is basically a unix timestamp with zone offeset already calculated and parsing the result yields a local time value shifted to GMT. Zone is not part of the output here, so it's effectively the same as Y-m-d local date. We not use the current time in Y-m-d notation on both ends without breaking or invalidating the present logic.
We use "WP timestamp" in combination with strftime in the tracking routine and retrieve WP Time in "Y-m-d" format for retrieval in the dashboard logic. While it is discouraged to work with "WP Timestamps" and strftime is deprecated as of PHP 8.1, is makes sense to use the same source of time on both ends. The present logic is not inherently wrong. The "WP timestmap" is basically a unix timestamp with zone offeset already calculated and parsing the result yields a local time value shifted to GMT. Zone is not part of the output here, so it's effectively the same as Y-m-d local date. We not use the current time in Y-m-d notation on both ends without breaking or invalidating the present logic.
We use "WP timestamp" in combination with strftime in the tracking routine and retrieve WP Time in "Y-m-d" format for retrieval in the dashboard logic. While it is discouraged to work with "WP Timestamps" and strftime is deprecated as of PHP 8.1, is makes sense to use the same source of time on both ends. The present logic is not inherently wrong. The "WP timestmap" is basically a unix timestamp with zone offeset already calculated and parsing the result yields a local time value shifted to GMT. Zone is not part of the output here, so it's effectively the same as Y-m-d local date. We not use the current time in Y-m-d notation on both ends without breaking or invalidating the present logic.
Describe the bug
We track visits in this line:
statify/inc/class-statify-frontend.php
Line 85 in 6675184
This is explicitly not recommended since WP 5.3:
https://make.wordpress.org/core/2019/09/23/date-time-improvements-wp-5-3/
https://developer.wordpress.org/reference/functions/current_time/#comment-3414
This saves a WP timestamp (not a correct UNIX timestamp) with
time()plus timezone adjustments if I understand correctly.But in
statify/inc/class-statify-dashboard.php
Line 321 in 6675184
Additionally
strftimeis deprecated in PHP 8.1 and it is strongly recommended to NOT use it anymore:https://www.php.net/manual/de/function.strftime.php
This would explain some reports of false data from the support forums.
Maybe there are more errors and deprecations in time functions. Needs more checks.
The text was updated successfully, but these errors were encountered: