Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0024934Openbravo ERPA. Platformpublic2013-10-11 17:132013-12-17 10:46
Reporteradrianromero 
Assigned ToAugustoMauch 
PriorityurgentSeveritymajorReproducibilityalways
StatusclosedResolutionduplicate 
PlatformOS5OS Version
Product Version3.0MP28.2 
Target Version3.0MP31Fixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0024934: Columns with reference Time are not displayed/stored properly
DescriptionDefine a field in postgresql of type 'timestamp without time zone' and in Openbravo define the reference of the column as 'Time'

In a window, if for example in the database the value is "2013-10-11 18:00:05" the value displayed in Openbravo is "22:00:05" but if we edit the record and change the value for example to "22:00:10", save, and reload then the value displayed is now "2:00:10" and in the database "2013-10-11 22:00:10"


This behaviour makes columns of time "Time" completely unusable.
Steps To ReproduceIn description.
Proposed SolutionIt seems that the problem is related to a bad management of time zones.

IMHO If value in database is "2013-10-11 18:00:05" it should display "18:00:05" In Openbravo and the other way the value edited in Openbravo is "18:00:05" it should store in the database "2013-10-11 18:00:05" (the date part is not important).
Additional Information
TagsNo tags attached.
Relationships
duplicate of defect 0025274 closed AugustoMauch The time fields are not working properly 
related to defect 0020684 closed AugustoMauch Incorrect time in process request with different timezones in client/server 
Attached Filesdiff solve_time.diff (1,663) 2013-10-24 11:32
https://issues.openbravo.com/file_download.php?file_id=6463&type=bug
Issue History
Date ModifiedUsernameFieldChange
2013-10-11 17:13adrianromeroNew Issue
2013-10-11 17:13adrianromeroAssigned To => AugustoMauch
2013-10-11 17:13adrianromeroModules => Core
2013-10-11 17:13adrianromeroTriggers an Emergency Pack => No
2013-10-11 17:17adrianromeroDescription Updatedbug_revision_view_page.php?rev_id=5094#r5094
2013-10-11 17:17adrianromeroSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=5096#r5096
2013-10-11 17:17adrianromeroProposed Solution updated
2013-10-24 11:30mtaalRelationship addedrelated to 0020684
2013-10-24 11:31mtaalNote Added: 0061883
2013-10-24 11:32mtaalFile Added: solve_time.diff
2013-10-30 10:52ioritzCiaNote Added: 0061966
2013-11-15 10:00xabiermerinoversion => 3.0MP28.2
2013-11-15 10:00xabiermerinoTarget Version => 3.0MP31
2013-12-17 10:46alostaleRelationship addedduplicate of 0025274
2013-12-17 10:46alostaleStatusnew => closed
2013-12-17 10:46alostaleResolutionopen => duplicate

Notes
(0061883)
mtaal   
2013-10-24 11:31   
The attached diff will solve the reported issue. There is another requirement to store absolute times (so the user enters 10:00 am, the database also shows 10:00 am). This is a separate topic for which a separate solution is planned to be done.
(0061966)
ioritzCia   
2013-10-30 10:52   
There is an End Client suffering this issue and therefore, it becomes an obps issue.