Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0031177Openbravo ERP01. General setuppublic2015-10-19 19:152022-02-01 08:09
amayavicente 
Triage Platform Base 
normalmajoralways
acknowledgedopen 
5
 
 
Core
No
0031177: Time in Process Monitor || Process Request || Process Log is the server time instead the user time
For background processes, in the field Process Monitor || Process Request || Process Log, the time is different that the time in the field Start time.
In a server with a different time zone that the user time zone, execute any process background.
When the process finish, check that in the field Process Monitor || Process Request || Process Log, the time is different that the time in the field Start time.
The time in the process log should be the time of the user who execute the process.
No tags attached.
Issue History
2015-10-19 19:15amayavicenteNew Issue
2015-10-19 19:15amayavicenteAssigned To => Triage Finance
2015-10-19 19:15amayavicenteModules => Core
2015-10-19 19:15amayavicenteTriggers an Emergency Pack => No
2015-10-19 19:17networkbResolution time => 1446418800
2015-10-20 09:30vmromanosAssigned ToTriage Finance => platform
2015-10-20 12:37eduardo_ArgalResolution time1446418800 =>
2015-10-20 12:37eduardo_ArgalTypedefect => design defect
2015-10-21 08:51alostaleNote Added: 0081163
2015-10-21 08:51alostaleStatusnew => acknowledged
2015-10-21 12:31alostaleNote Edited: 0081163bug_revision_view_page.php?bugnote_id=0081163#r9762
2022-02-01 08:09alostaleAssigned Toplatform => Triage Platform Base

Notes
(0081163)
alostale   
2015-10-21 08:51   
(edited on: 2015-10-21 12:31)
The problem is process log is saved as plain text, including for each line a timestamp within server's timezone. Displaying this timestamp in client's timezone is not possible without parsing and converting it in client side.

Different approaches could be implemented, though none of them would be optimal:

1. Log text is saved as it is now and parsed in client to convert it to local timezone. This should be done both in grid and form views. Problem:
  * It could lead to performance problems in browser.
  * Big implementation effort

2. Process log is not saved as plain text but in a new table where each line is a record with two fields: text and time. In this manner standard time conversion would be performed. Problems:
  * Major change in the manner log is created and visualized
  * Possible performance issues due to massive records generation in this new table
  * Backwards compatibility: old logs wouldn't be migrated to new system, so they could not be visualized anymore.

3. Log timestamp is created in client's timezone instead of sever's one. Problems:
  * We would still have the same problem when logs are visualized from clients in different timezones
  * From browser it is possible to know current offset with UTC but not timezone. This would mean processes scheduled in timezones with DST would be incorrectly logged after time change, this would mainly affect to recurring scheduled jobs.

4. Keep current logging including current timezone info. In this way a line like: "2015-10-21 08:46:49.16 - Starting background process." would be created as "2015-10-21 08:46:49.16 CEST - Starting background process.". This would, at least, make visible the actual timezone the log is for. Problems:
  * There is no immediate time transformation but user needs to do the calculations if needed
  * Not backwards compatibility: existing logs would be kept as they are now

5. Log elapsed time since the process started instead of date time. As start time is also displayed in the same window properly translated to client's time zone, complete information would be available. Problems:
  * Behavioral change: now process time instead of timestamp would be shown
  * Not backwards compatibility: existing logs would be kept as they are now