ssf - time rounding for seconds #3006
No reviewers
Labels
No Label
DBF
Dates
Defined Names
Features
Formula
HTML
Images
Infrastructure
Integration
International
ODS
Operations
Performance
PivotTables
Pro
Protection
Read Bug
SSF
SYLK
Style
Write Bug
good first issue
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sheetjs/sheetjs#3006
Loading…
Reference in New Issue
No description provided.
Delete Branch "davidtamaki/sheetjs:davidtamaki/ssf-duration-rounding"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This fixes the edge case where microseconds round a date/time with 59 seconds to the next minute.
before:
after:
Matches what we see in sheets:
I looked in to updating this here with the following logic, however this will keep seconds at 59 instead of rounding up through the larger timeframes (minutes, hours, etc):
Also fixes: https://github.com/SheetJS/ssf/issues/95
If this fix looks good - could this get ported to the https://github.com/SheetJS/ssf npm package?
Thanks for the report and PR!
The fractional part of
v
is the time, so you would need to round to the nearest second (1/86400):It's useful to have a small test harness (see attached file):
Logged values are (R-1, C-1, value, format, expected, actual)
There are 18 divergences with the current code, 15 with the original patch, and 11 after correcting the rounding.
Some of the issues have to do with rounding when no seconds or microseconds are specified (
h:mm
). Others relate to treatment of absolute hours in the presence of date specifiers.We'll take a closer look. If you have any other rounding cases, we'll throw them into the test.
Thanks for the feedback!
I added another check which resolves 2 of the divergences of that test relating to the
h:mm
format.Of the remaining 9 divergences, I'm wondering if this may be an issue with
XLSX.readFile
rather thanSSF.format
. I've copied the sheet to here and highlighted the differences.The remaining 9 divergences match the results we see in that spreadsheet (with the caveat that Google sheets apparently starts time 2 days before excel at
1899-12-30 0:00:00
vs1900-01-00 0:00:00
, but the times do match)One of the expected results is also off, but it doesn't appear to be related to rounding issues:
@sheetjs is there anything else I need to do on this PR? I'd like to get this change merged in if there are not any further issues / tests to run. Thanks!
yyyy-mm-dd [h]:mm:ss
is definitely bugged in Excel.The absolute hours field is clearly wrong given the values (since none of the values exceed 1, the absolute hours should not exceed 24).
PS:
XLSX.readFile
does not actually format the values in this test. The test file uses theTEXT
function, ensuring that Excel serializes the formatted text. For example, in the attached file, C4 is stored as follows:We ended up having to shift the rounding logic elsewhere. To summarize, Excel enforces 15 decimal digits precision.
#3003 has a more detailed example with numbers.
After more precise rounding rules, a few of the disabled tests also passed 🥳
Version
0.11.3
has been released.Standalone script
URL: https://cdn.sheetjs.com/ssf-0.11.3/ssf.js
Adding to a page:
Live Demo: https://jsfiddle.net/vz0h9Lxd/
NodeJS package
URL: https://cdn.sheetjs.com/ssf-0.11.3/ssf-0.11.3.tgz
Installation:
Package installs to module name
ssf
so it should be a drop-in replacement for the legacy distribution point.Thanks @sheetjs !
Are there any plans to publish
0.11.3
to npm? Or should we no longer expect any updates to that repo? Ideally we would prefer to use npm as a distribution point.The SheetJS CDN https://cdn.sheetjs.com/ is the authoritative source for SheetJS modules.
Legacy distribution points (including the
SheetJS/sheetjs
Git repositories on GitHub and thessf
package on npmjs.com) will not be receiving updates.Vendoring
The dependency tarball can be "vendored" in your repository:
vendor
subfolder:file:
prefix tells the NPM client that the specified name is a tarball:In general, it is strongly recommended to use a proxying registry like Verdaccio
Nested Dependency
If
ssf
is a dependency of a dependency, you can add an override topackage.json
:This can be combined with the "Vendoring" approach:
Thanks for the clarification!