[Octave-bug-tracker] [bug #62246] [octave forge](io) xlsread miscalculates serial date number using UNO interface

[anonymous]

Follow-up Comment #5, bug #62246 (project octave):

First - sorry for the late reply. It was a bit hectic this week. 

I unzipped the .ods as you told me (thank you!) and I think I've got the
problem in the original file (which I can't share, sorry) down: 

<table:table-cell table:style-name="ce811" office:value-type="string"
calcext:value-type="string">
<text:p>19.08.2008</text:p>

So what happened, was:
- the .ods (exported from the .xls) contains a date-column in mixed format
(dots, dashes, German, American) that is only partially formatted as dates,
the rest are strings; it used to be only human-readable, so not a problem for
10+ years
- I saw that xlsread() has an optional rawdata output, which contained the
correct serial date numbers (Linux, Octave 6.3, UNO-interface for xlsread), I
happily used that rawdata to export the dates to our SQL database
- someone else ran the same script (Windows10, Octave 6.3, UNO-interface), the
string-formatted DD.MM.YYYY """date""" did not get recognised as a date, thus
the epoch difference wasn't added
- when we tried to reproduce this we discovered that a different interface,
like OCT, recognises the DD.MM.YYYY-string as a date on both systems

... I agree that this isn't actually a bug (I was too quick to post this, I
should have checked the content.xml first), but it's a rather nice feature of
the interfaces? The note in the io-package you quoted should cover that
hiccup. 
Again, sorry that I didn't check it more thoroughly before posting.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62246>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/