Project

General

Profile

Actions

Bug #85602

closed

The date and time are wrong in the log module view

Added by Rachel Foucard almost 6 years ago. Updated 28 days ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Backend User Interface
Target version:
-
Start date:
2018-07-20
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
8
PHP Version:
7.0
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Hello,

When I compare the history/undo log of actions and the log module for the same actions :
  • history/undo log : the date and time are correct
  • log module : the date is 1 day less and the time is 1 hour less
Screenshots for the comparaison of 1 action :
  • php.ini timezone

  • log module view

  • history/undo view

  • database record

thank you in advance,
Rachel Foucard


Files

phpini.JPG (36.4 KB) phpini.JPG Rachel Foucard, 2018-07-20 11:31
logmodule.JPG (40.5 KB) logmodule.JPG Rachel Foucard, 2018-07-20 11:33
historyundo.JPG (76.1 KB) historyundo.JPG Rachel Foucard, 2018-07-20 11:33
database.JPG (27.5 KB) database.JPG Rachel Foucard, 2018-07-20 11:36

Related issues 2 (1 open1 closed)

Related to TYPO3 Core - Epic #80852: Datetime handling in backendClosed2016-10-27

Actions
Related to TYPO3 Core - Epic #77562: Misbehaviors with datetime values and timezonesAccepted2012-05-17

Actions
Actions #1

Updated by David Bruchmann almost 6 years ago

  • Related to Epic #80852: Datetime handling in backend added
Actions #2

Updated by David Bruchmann almost 6 years ago

  • Related to Epic #77562: Misbehaviors with datetime values and timezones added
Actions #3

Updated by Sybille Peters almost 6 years ago

  • Description updated (diff)

Hint: If anything I wrote here helps to reproduce / narrow down / fix problem, ignore the rest. Meaning: you don't have to try it all and answer it all, these are just some ideas to narrow down the problem a little bit further.

date.timezone in your php settings screenshot shows "America/Los_Angeles". On Slack you said CET, correct? CET is 1 hour difference from UTC. So this does not account for the values you are reporting, but it is not consistent, so I guess it's worth a try to set it up consistently.

Please try the following:
  • setup date.timezone (php.ini) correctly for your timezone, e.g. "Europe/Paris" (see: http://php.net/manual/de/timezones.europe.php)
  • Use the same for $GLOBALS['TYPO3_CONF_VARS']['SYS']['phpTimeZone'] (install tool configuration)

See if this changes results or you can still reproduce.

Actually I think it should be enough to set one or the other, but the timezone may not always be evaluated consistently in the core. What you see is probably a bug, but I can't reproduce it yet and it would be great if we could narrow this down some more.

I assume you are using latest 8.7.17.

Are you using workspaces?

Another hint: It's easier to read the issue reports if you insert the images inline (e.g. ) or copy-paste the relevant values (as far as they are actually readable that way) as text.

Also:

The date listed in the database record is yet another different date:

tstamp=1532077352 evaluates to Fri Jul 20 11:02:32 CEST 2018

date --date='@1532077352'

In the details, it says 'User changed workspace ...'. So are you sure, this is the corresponding one? For inserting a record, I get something like 'Record '%s' (%s) was inserted on page '%s' (%s)' in the sys_log, so you can search sys_log with something like:

SELECT FROM_UNIXTIME(tstamp), tstamp, details,tablename,recuid FROM sys_log WHERE details LIKE '%inserted%' AND tablename = 'tt_content' ORDER BY tstamp DESC LIMIT 10;

or a combination of sys_log / history:

SELECT FROM_UNIXTIME(log.tstamp),FROM_UNIXTIME(history.tstamp),log.action,log.details,log.recuid,log.tablename FROM sys_log log LEFT JOIN sys_history history ON log.uid=history.sys_log_uid WHERE log.details LIKE '%inserted%' AND log.tablename='tt_content' ORDER BY log.tstamp DESC LIMIT 10;
Actions #4

Updated by Riccardo De Contardi over 5 years ago

  • Status changed from New to Needs Feedback

Is this issue still valid? May I ask you please to add further details as Sybille Peters asked on her last comment? Thank you.

Actions #5

Updated by Rachel Foucard over 5 years ago

Hello Riccardo,

yes of course, sorry I didn't answer because I didn't received the alert mail about the Sybille message! I'm going to test the different suggestions and answer that.
Rachel

Actions #6

Updated by Rachel Foucard over 5 years ago

Hello,

I did the test again this morning, and the problem disappeared even though I didn't change any settings. On the other hand, we have switched to winter time since 27 October, I think that's what has fixed the problem for the next 6 months.

Cheers,
Rachel

Actions #7

Updated by Riccardo De Contardi about 5 years ago

  • Status changed from Needs Feedback to New

Thank you for your answer and sorry for my late reply. I change for now the status of this issue to "new" - it seems that the issue, as far as I have understood, is about winter time/daylight savings time not considered.

Actions #8

Updated by Rachel Foucard about 5 years ago

Thank you Riccardo,

yes it seems to be "just" a winter time problem. And unfortunately the European Commission does not seem to have convinced all countries to stop this in 2019...
Cheers,
Rachel

Actions #9

Updated by Susanne Moog about 4 years ago

  • Category set to Backend User Interface
Actions #10

Updated by Markus Klein 28 days ago

  • Status changed from New to Closed

Can't reproduce on 11.5.33. Closing..

Actions

Also available in: Atom PDF