Don't misinterpret colors as dates #559
Conversation
|
Thanks for tacking this! Do we know if similar code is already in use somewhere and is therefore a bit battle-tested? It would be very reassuring to use a variant of something that is proven to work. |
|
Hmm, this does deserve more work. I hadn't really set aside time for it so I'll be a bit slow coming back to it. Tidyxl has used this code for a while, but that's hardly battle tested so I'm comparing it with xlrd, which takes a similar approach. There are subtle bugs in both. |
|
It doesn't have to be perfect -- we have a rather large bug at the moment. But it's our bug and it seems to cause very few problems and I would hate to implement a solution that caused a net increase in user pain. |
|
In the Chinese, Japanese, and Korean versions of Excel, the default representation of "number" is "0_);[Red](0)". |
jennybc
changed the title
Add a test and test file based on a format where the confusion can come via currency, not colour. Link to issues. We generally incorporate `-xls` or `-xlsx` into test file names, so the format is obvious even if the file is open in Excel. Added the actual implicit number formats in comments.
Fixes #388
Closes #692
This caught me again recently.
Excel number formats support colours for, e.g. negative values
0.00;0.00[Red]. Currently thedinRed(and some letters of other colours) is confused with thedin a date formatdd/mm/yyyy, so the cell is incorrectly treated as adatecell.The tests force a warning if this happens, by explicitly setting
col_type = "numeric".The 'lowercase' variant of the test spreadsheet uses
red(and similar) rather thanRed, because this is allowed by the spec, though Excel itself doesn't create such files.