Date one day behind in dashboard

Hi Peer,

you’re talking about the date shown in the tooltip of the rightmost chart entry, right?

Obvious question in advance: Is there data for “today” that could be shown?
If Statify didn’t count anything (correctly or by error), nothing can be displayed, as we do not fill gaps yet.

also after the 1.7.2 update […]

1.7.2 fixed the number days evaluated for the top lists, not the chart. However the fix only affected the oldest entry (e.g. with 14 days configured, “today – 14” had been evaluated, so 15 days in total).

The definition of “today” has changed in 1.7.0 though. Statify now only relies on the PHP server date where the database server date had been evaluated for the dashboard output before. Both times obviously don’t need to match for several reasons.

I cannot reproduce your issue on several test and live sites, all of them show 03.07.2020 (which is correct now at 09:50 CEST).

Is your WP date and time(zone) correct? (can easily be verified on the general settings page, all examples there are generated from current timestamp)

Cheers,
Stefan

Hallo Stefan,
es gibt auf der Website auch massig an Besuchern. Es gibt also schon 3 Minuten nach Mitternacht Daten in Statify.

In den WP-Einstellung wird das korrekt Datum angezeigt. Berlin ist als Zeitzone ausgew?hlt.

Ich habe per PHP Code auch mal das aktuelle Datum ausgelesen und da wird auch der heutige Tag angegeben.

Nur im Dashboard wird im Tooltip des aktuellen Tages das Datum von gestern angezeigt.

Ich habe mal in widget-front.php ein wenig geschaut und Daten ausgegeben. Wenn ich mit PHP $visit[‘date’] ausgeben, dann ist das das Datum von heute. Wenn ich aber per PHP date_i18n( get_option( ‘date_format’ ), strtotime( $visit[‘date’] ) ); ausgebe, dann das Datum von gestern.

Die Funktion date_i18n scheint also das korrekt übergebene $visit[‘date’] in das falsche lesebare Datum umzuwandeln, n?mlich einen Tag zuvor.

Hier scheint das Problem schon beschrieben worden zu sein:
https://www.ads-software.com/support/topic/wrong-date-day-1/

Wenn ich aber per PHP date_i18n( get_option( ‘date_format’ ), strtotime( $visit[‘date’] ) ); ausgebe, dann das Datum von gestern.

Mit WP 5.3 wurde diese Funktion ge?ndert:

Date/Time component improvements in WordPress 5.3

date_i18n() ist nur noch ein Wrapper für wp_date().
https://developer.www.ads-software.com/reference/functions/date_i18n/
https://developer.www.ads-software.com/reference/functions/wp_date/

Ich befürchte, diese Wrapper-Funktion korrigiert hier etwas, was sie gar nicht korrigieren sollte und erzeugt so den Fehler erst.

Wenn wir mal davon ausgehen, müsste die Original-Funktion funktionieren.

Zeigt dieser Code das richtige Datum an:

wp_date( get_option( ‘date_format’ ), strtotime( $visit[‘date’] ) );

Wenn ja, dann sollten wir diese (deprecated) Wrapper-Funktion vermeiden und direkt wp_date nutzen.

Freue mich auf ein kurzes Feedback! Danke schon mal fürs Testen, Peer!

Beste Grü?e
Torsten

Ich habe diese wp_date-Funktion nun mal in 2 Blogs getestet. Zum einen in dem Blog, wo es das -1 Tag Problem im Dashboard gab. Das ist nun behoben und es wird der korrekte Tag im Tooltip angezeigt.

In einem anderen Blog, wo es vorher schon korrekt war, ist es immer noch korrekt.

Also alles in Ordnung, soweit ich das beurteilen kann.

Danke dir.

• This reply was modified 4 years, 4 months ago by Madd1974.

Vielen Dank nochmal fürs Testen und best?tigen meiner Theorie, @madd1974 !

@stklcode ich mache dazu mal ein Issue auf Github auf.

Beste Grü?e
Torsten

Joah… Ich zitiere aus dem WP Core Code: “This is the best attempt to reverse that operation into a local time to use.”

Der übergebene Zeitpunkt wird als UTC gesehen und der Offset (erneut) herausgerechnet. Meine Vermutung hier w?re, dass es von der System und/oder PHP-Zeitzone abh?ngt, was die Rechnung hier tut. Auf meinem lokalen Testsystem (alle Zeitzonen einheitlich Europe/Berlin) passt es. Im Container (System+PHP auf UTC, WP Berlin) verschiebt es sich nach vorne, was unkritisch ist. Aber eben so kann ein negativer Offset reinkommen, dann sind wir bei Uhrzeit 00:00:00 (wir speichern ja nur das Datum) eben einen Tag zurück.

Wir speichern hier bereits “lokale” Zeitstempel, d.h. die Zone interessiert uns bei der Ausgabe gar nicht mehr. Wir sollten also entweder alles als “UTC” ansehen oder Konversion g?nzlich ignorieren (z.B. gem?? Thorstens Vorschlag).

Gru?,
Stefan

Hallo Peer,

dank @stklcode wird die n?chste Statify-Version 1.7.3 ein Bugfix hierfür enthalten.

Viele Grü?e
Patrick