Live data from Hacker News

Why are the Microsoft Office file formats so complicated? (And some workarounds)

joelonsoftware.com

21–22 of 22 posts

Re: Why are the Microsoft Office file formats so complicated? (And some workarounds)

#21
post #7
post #4

"If you simply have to produce tabular data for use in Excel, consider CSV." That's what most of us have been doing for years, simply to avoid the mess discussed in this article. After reading the article, I, for one, will keep on doing it.

I ran into a nasty bug(?) recently in the way Excel processes CSVs. I create a well formed CSV from a Java Web app which the user downloads. They open the CSV up in Excel and modify the data for an eventual upload. However, during the save process, Excel truncates trailing commas. Which causes my well formed CSV to be a poorly formed CSV during upload and parsing. Not fun.

For such type of thing you should always have something at the last column, even return might be enough

A,B,,,,,,,," " C,D,,,,,,,," "

That's newline there between " and "

I guess Excel loads that internally through a convertor, trims the rightmost unused columns, and then saves it that way.

Re: Why are the Microsoft Office file formats so complicated? (And some workarounds)

#22

It seems to me like Joel has a rather warped view of how software should be built. He claims It means you have to rewrite all of your date display and parsing code to handle both epochs. That would take several days to implement, I think. That's just ridiculous. In my mind, you need a piece of code that reads the 1904 record and sets a flag in the code. Then, your date display and parsing code should all call one, or…

I'm fine with being downmodded, but I'm curious why. I know that Joel has a lot of articles submitted here and that me questioning his insights is probably not a good idea (in terms of karma, at least), but does someone actually think that implementing code to handle different epochs should take several days?
Post reply on HN