OK I see. It did not work here in Excel because my version is localized and requires a "t" instead of the "d" symbol.
If you want your data being formatted as "13 days" then you mean implicitely that you consider the numbers as time intervals. But now there is a problem even in the Excel format: The symbol "d" in the date format string is replaced by the day number of the calendar date, e.g. by 27 for today's date (Jan 27). This works fine as long as the date number is within January. But try the number 32.79875 with your format string [>=1]d \days hh:nn:ss;hh:nn:ss, and see what happens -- there's an overflow back to 1.
The correct way would be, in my eyes, to introduce a square bracket syntax as it exists for hour, minute and second time intervals, i.e. provide a [d] symbol (like [h], [n], [
s]). But this will not be implemented probably because it is not used neither by Excel for by LibreOffice Calc.
If you are willing to accept this possible overflow issue you can use the format string 'd "days" hh:nn:ss' in fpspreadsheet which extracts the day number and inserts the "days" word.
But now there is another problem: Leap year 1900 problem... For some reasons (
http://www.cpearson.com/excel/datetime.htm), this is neglected in Excel, but it is respected correctly byLibreOffice and fpspreadsheet. This means that the day numbers are off by 1 before March 1 1900 between Excel on one side and LibreOffice/fpspreadsheet on the other side. (And as I noticed there is a bug in fpspreadsheet because Feb28,1900 appears a second time on March 1 -- I'll fix this soon).
Of course, when you export files only for Excel, not for Calc, and you do not plan to load them into fpspreadsheet you still can use the 'd "days" hh:nn:ss' format string.