Bug 54071 - DateUtils.getXX() do not round millisecond values leading to Dates being different by one second compared to LibreOffice
Summary: DateUtils.getXX() do not round millisecond values leading to Dates being diff...
Status: NEW
Alias: None
Product: POI
Classification: Unclassified
Component: XSSF (show other bugs)
Version: 3.8-FINAL
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords: APIBug
Depends on: 56269
Blocks:
  Show dependency tree
 
Reported: 2012-10-30 09:14 UTC by applepaihs
Modified: 2015-01-05 08:05 UTC (History)
0 users


Attachments
jpg and programe (7.05 KB, application/x-rar)
2012-10-30 09:14 UTC, applepaihs 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description applepaihs 2012-10-30 09:14:53 UTC 
Created attachment 29525 [details]
jpg  and  programe

20 rows ,  half of them is cover 59secend to  58
Comment 1 Dominik Stadler 2013-07-01 08:49:11 UTC 
The XLSX contains two slightly different native values for the timestamps:

The first 9 rows contain 41224.999988425923, the others 41224.999988368058, it seems POI computes a slightly different time for the second value.
Comment 2 Dominik Stadler 2013-07-09 13:51:07 UTC 
There is now a reproducer-test in TestUnifxedbugs for this Bug.
Comment 3 Dominik Stadler 2015-01-04 22:42:09 UTC 
I could get this to lead to equal dates by setting the parameter "roundSeconds" in DateUtils.getJavaDate() to "true", however there might be some side-effects so I am not sure if this is really the correct fix here as many other places still would call it with "false" via other code-pathes. 

We probably should decide if we should do this rounding always without the additional parameter to avoid the error-prone different handling of this conversion.
Comment 4 Andreas Beeker 2015-01-05 00:37:00 UTC 
As stated in #56269 I'm +1 for using the rounding as the default.