Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0044640Openbravo ERP01. General setuppublic2020-07-20 14:362020-07-27 10:25
a_singh 
cberner 
immediatemajoralways
closedfixed 
5
3.0PR19Q4.4 
PR20Q4 
alostale
Google Chrome
Core
Production - Confirmed Stable
2019-09-23
3.0PR19Q4
https://gitlab.com/openbravo/product/openbravo/-/commit/4ec715bfa9c6bc0ab7b3e6f644ec05ef4998c721 [^]
No
0044640: Exported grid csv with enabled creation date column value does not match in the application
In 19Q4.4, despite the preference Local Timezone ID defined, when the user tries to export any of the window grid with enabled Creation Date column.The creation date value exported in the csv file does not matches in the grid.
Following steps to be followed:

1. Log in the backoffice as Openbravo/openbravo

2. Go to the Preference window
   a.Preference Property: Local Timezone ID
   b.Property List: Yes
   c.Selected: No
   d.Value: America/New_York

3. From any window grid, enable the Creation Date column and click on the Export to csv toolbar button.

4. The expected value is Creation Date value should be in US Eastern Time Zone but the value is in UTC timezone.
No tags attached.
depends on backport 0044681PR20Q3 closed cberner Exported grid csv with enabled creation date column value does not match in the application 
depends on backport 0044682PR20Q2.1 closed cberner Exported grid csv with enabled creation date column value does not match in the application 
depends on backport 0044683PR20Q1.3 closed cberner Exported grid csv with enabled creation date column value does not match in the application 
caused by defect 0038671 closed alostale random NPE getting data for some date/datetime fields 
related to defect 0044574 closed cberner The date is not displayed correctly in the "Costing Rules" window -> "Fix Backdated Transactions" process 
Issue History
2020-07-20 14:36a_singhNew Issue
2020-07-20 14:36a_singhAssigned To => Triage Finance
2020-07-20 14:36a_singhWeb browser => Google Chrome
2020-07-20 14:36a_singhModules => Core
2020-07-20 14:36a_singhTriggers an Emergency Pack => No
2020-07-20 15:20egoitzWeb browserGoogle Chrome => Google Chrome
2020-07-20 15:20egoitzResolution time => 1597010400
2020-07-20 15:30a_singhIssue Monitored: a_singh
2020-07-20 15:54dmiguelezAssigned ToTriage Finance => platform
2020-07-24 11:18cbernerWeb browserGoogle Chrome => Google Chrome
2020-07-24 11:18cbernerRegression level => Production - Confirmed Stable
2020-07-24 11:18cbernerRegression date => 2019-09-23
2020-07-24 11:18cbernerRegression introduced in release => 3.0PR19Q4
2020-07-24 11:18cbernerRegression introduced by commit => https://gitlab.com/openbravo/product/openbravo/-/commit/4ec715bfa9c6bc0ab7b3e6f644ec05ef4998c721 [^]
2020-07-24 11:18cbernerPrioritynormal => immediate
2020-07-24 11:18cbernerAssigned Toplatform => cberner
2020-07-24 11:19cbernerStatusnew => scheduled
2020-07-24 13:33hgbotNote Added: 0121609
2020-07-27 07:14alostaleRelationship addedcaused by 0038671
2020-07-27 09:50cbernerRelationship addedrelated to 0044574
2020-07-27 10:04hgbotResolutionopen => fixed
2020-07-27 10:04hgbotStatusscheduled => closed
2020-07-27 10:04hgbotFixed in Version => PR20Q4
2020-07-27 10:04hgbotNote Added: 0121612
2020-07-27 10:04hgbotNote Added: 0121613
2020-07-27 10:25cbernerReview Assigned To => alostale
2020-07-27 10:25cbernerWeb browserGoogle Chrome => Google Chrome

Notes
(0121609)
hgbot   
2020-07-24 13:33   
Merge Request created: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/108 [^]
(0121612)
hgbot   
2020-07-27 10:04   
Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/openbravo [^]
Changeset: 31a86688c4d60c62dd97f3fd8de096e01869b832
Author: Cristian Berner <cristian.berner@openbravo.com>
Date: 2020-07-27T09:31:22+02:00
URL: https://gitlab.com/openbravo/product/openbravo/-/commit/31a86688c4d60c62dd97f3fd8de096e01869b832 [^]

Fixes ISSUE-44640: Sets correct DateTime in window grid exported CSV file

DateTime in export to CSV was wrong, applying local time zone several times instead of once.

It has been fixed by using a function that doesn't try to transform to
UTC in DateTimeUIDefinition, convertToClassicStringInLocalTime. This
function formats the date as is, using the timezone received without
prior conversion to UTC.

---
M modules/org.openbravo.client.kernel/src/org/openbravo/client/kernel/reference/DateTimeUIDefinition.java
M modules/org.openbravo.service.datasource/src/org/openbravo/service/datasource/DataSourceServlet.java
---
(0121613)
hgbot   
2020-07-27 10:04   
Merge request merged: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/108 [^]