BUG? - Calc does not show same XLS dates

Discuss the spreadsheet application
Post Reply
DutchGemini
Posts: 7
Joined: Mon Jan 21, 2008 10:16 am

BUG? - Calc does not show same XLS dates

Post by DutchGemini »

I have received a very rudimental, 1-sheet, XLS file and have opened it at home on my OO 2.3 (Italian)

The values that I see in Calc are NOT those I see when I open the same file in Excel.

In Calc:
As Calc see the XLS file
As Calc see the XLS file
AsCalcSeesIt.png (11.15 KiB) Viewed 4743 times
In Excel:
As Excel sees the same file
As Excel sees the same file
AsExcelSeesIt.png (7.84 KiB) Viewed 4744 times
Apart the formatting, the BIG problem are the dates. There is an enormous discrepancy between the ones from Excel and those listed in the first column of Calc. Considering that the file originated in Excel 2003 and as such I must trust the contents, then IMHO Calc has a serious bug here.

XLS file is attached.
Attachments
Trasloco21-25 gennaio08.xls
The XLS file that shows the mismatch
(33.5 KiB) Downloaded 296 times
User avatar
kingfisher
Volunteer
Posts: 2123
Joined: Tue Nov 20, 2007 10:53 am

Re: BUG? - Calc does not show same XLS dates

Post by kingfisher »

Calc and Excel use different start dates.

For the setting in Calc see Menu: Tools >Options >OOCalc >Calculate : Date which according to Help:
Help wrote:Select the start date for the internal conversion from days to numbers.
12/30/1899 (default)
Sets 12/30/1899 as day zero.
01/01/1900 (StarCalc 1.0)
Sets 1/1/1900 as day zero. Use this setting for StarCalc 1.0 spreadsheets containing date entries.
01/01/1904
Sets 1/1/1904 as day zero. Use this setting for spreadsheets that are imported in a foreign format.
Apache OpenOffice 4.1.9 on Linux
User avatar
ccornell
Volunteer
Posts: 611
Joined: Sun Oct 07, 2007 7:21 am

Re: BUG? - Calc does not show same XLS dates

Post by ccornell »

Check the years that are assigned to the cells that are one day out. When I opened the spreadsheet and looked at the cells in question, they all had 1900 as the year instead of 2008. The change in days displayed is probably down to the difference in how Calc and Excel handle 1900. Excel has a known bug that was purposely included in the code... Excel (at least some versions) considers 1900 to be a leap year even though it is not. See this webpage for more info: http://support.microsoft.com/kb/214326 The short of it is that the dates are out by one day for dates before 1 March 1900.

So.. check your source. The error is not in Calc as far as I can tell. Calc handles the dates correctly as they were input into your spreadsheet. Open the spreadsheet in Excel, correct the years in the cells with the wrong year. Save the corrected spreadsheet and open it in Calc. The dates should be displayed as you expect them to be.
openSUSE 11.4, KDE4.6 with OpenOffice.org 3.3
User avatar
Villeroy
Volunteer
Posts: 31279
Joined: Mon Oct 08, 2007 1:35 am
Location: Germany

Re: BUG? - Calc does not show same XLS dates

Post by Villeroy »

You may also apply some format which includes the year:
2008-01-21
2008-01-21
2008-01-21
2008-01-21
1900-01-21
1900-01-21
1900-01-21
2008-01-22
2008-01-23
2008-01-23
2008-01-24
1900-01-23

The real numeric values in the first column, converted by function N():
39468
39468
39468
39468
22
22
22
39469
39470
39470
39471
24
The spreadsheet is formatted to death and it demonstrates an Excel bug. It's a known matter of fact that Excel fails with dates <1900-02-01 since it treats year 1900 as leap year which is plain wrong.
Please, edit this topic's initial post and add "[Solved]" to the subject line if your problem has been solved.
Ubuntu 18.04 with LibreOffice 6.0, latest OpenOffice and LibreOffice
DutchGemini
Posts: 7
Joined: Mon Jan 21, 2008 10:16 am

Re: BUG? - Calc does not show same XLS dates

Post by DutchGemini »

I knew the dates were based on '1900', I've seen it myself, but I do not want to change this. The book did not come from me.

Unfortunately, I see in this small thread something I have been seeing many times in the past, and that people that work or sponsor open source software often make the mistake to think or pretend their tools to be better than Microsoft stuff.

Although this may be true, for the time being Excel has by far the numbers for being the leader on the spreadsheet market, and whether you like it or not, any tool including Calc must follow and show its compatibility. Once it will have the numbers, then it can start being a standard.

Now, if the problem is caused by Excel having (intentionally) a bug, then Calc is simply said NOT compatible with Excel. If that means that Calc should take over this bug (and all other known bugs), then let it be. I am one of the [elected?] few that is stubborn enough to use OO (ok, at home, but what the heck) while all sources that I interact with use Excel which means that I have to adapt. I do not want to become the incompatible factor. How many bugs in Excel are 'corrected' by Calc?

I was already thinking about switching back to MS-Office after having had usability problems in Writer (amongst other duties, I write software manuals and I deal a lot with pictures/screendumps and compared to MS-Word it is to be honest very cumbersome). Since it is a lost battle for me having to constantly crosscheck the dates before I can continue working with workbooks from other people, I stopped using Calc, made the move and are now working stable with Excel (and Word) again.
User avatar
ccornell
Volunteer
Posts: 611
Joined: Sun Oct 07, 2007 7:21 am

Re: BUG? - Calc does not show same XLS dates

Post by ccornell »

DutchGemini wrote:Now, if the problem is caused by Excel having (intentionally) a bug, then Calc is simply said NOT compatible with Excel. If that means that Calc should take over this bug (and all other known bugs), then let it be.
So... you're saying that because Microsoft makes a mistake and perpetuates a bug in their software that everyone else should copy that error? That makes no sense at all. No software vendor should ever copy known bugs into their product... open source or otherwise. That perpetuates the problem.

If the original author of the spreadsheet had entered his or her dates correctly in Excel (ie used 2008 instead of 1900), there would be no problems. Even Excel will produce incorrect results with bad data - say you perform a date calculation (in Excel) on the dates given... will you get a correct result when some dates are 1900 (in error) and some are 2008?
openSUSE 11.4, KDE4.6 with OpenOffice.org 3.3
User avatar
acknak
Moderator
Posts: 22756
Joined: Mon Oct 08, 2007 1:25 am
Location: USA:NJ:E3

Re: BUG? - Calc does not show same XLS dates

Post by acknak »

Yes, I've seen this arrogant attitude myself, that people who use MS Office think that the world revolves around "the way Excel does it", or "that's the answer I got in Excel, so it must be right".

In all seriousness, OOo is not right for everybody, and Calc is not right for you. I consistently recommend that people who need to share working documents with MS Office users should not use OOo--at least not without very careful consideration and testing--for exactly the reasons you listed. Life is hard enough without worrying about software compatibility introducing more problems.

Even so, using only MS Office and having spreadsheets with bogus data in them is going to bite you in the... rear end at some point.
AOO4/LO5 • Linux • Fedora 23
DutchGemini
Posts: 7
Joined: Mon Jan 21, 2008 10:16 am

Re: BUG? - Calc does not show same XLS dates

Post by DutchGemini »

acknak wrote:Yes, I've seen this arrogant attitude myself, that people who use MS Office think that the world revolves around "the way Excel does it", or "that's the answer I got in Excel, so it must be right".
It has nothing to do with arrogance. And I have the clear impression that both of you did not read the story about the "1900 dates bug" in Excel. Excel introduced it to mimic the behaviour of 1-2-3 (the leader at the time) so that users could rapidly make the swap. This strategy paid off, people made the move to Excel and it became the market leader. Microsoft decided to maintain this behaviour in future releases and in fact it is still present. But it works fine.

Let me put it this way: whatever alternative software suite you want to propose, nobody (except those manifest against Microsoft) gives a damn about how good and how perfect the internal routines are developed and how many things are solved. They are simply interested in having a good product that allows them to work and share with the rest of the world. In this world, Microsoft Office is the 'de facto' standard for office documents, whether you (include me, I am a strong supporter of open source software) like it or not. Understand that the product is a tool and not a worship.

Calc claims to be Excel compatible and that it can read and write (I copy from OO's Calc page: "Of course, you are free to use your old Microsoft Excel spreadsheets, or save your work in Excel format for sending to people who are still locked into Microsoft products."). Then it should continue to behave like Excel. This means that whenever I explicitely enter 01-18-1900 in Excel, I must see the same value when I open Calc. And the other way around also.
acknak wrote:In all seriousness, OOo is not right for everybody, and Calc is not right for you. I consistently recommend that people who need to share working documents with MS Office users should not use OOo--at least not without very careful consideration and testing--for exactly the reasons you listed. Life is hard enough without worrying about software compatibility introducing more problems.
Here you got the point, and this is probably one of the major reasons why OO is still a niche player in the Office Suites business and confined to small realities. Do you really think it is normal that one needs to do very careful consideration and testing before being able to use OO as an alternative for Office? Common, be serious.
acknak wrote:Even so, using only MS Office and having spreadsheets with bogus data in them is going to bite you in the... rear end at some point.
No evidence of that. OO bit me instead.
Post Reply