[Solved] Date field bug?

[rab212]

Have there been any recent changes to the way a date field displays in Reports, or how it impacts other fields? I use Report Wizard.

I've been working with dates for a number of months now, without problems. Recently, though, a date field can turn off the preceding column, or cause a minus sign to appear before a positive integer, if that variable is in the preceding column.

This seems to be a variation on a bug that has been prevalent for awhile, where a numeric field trailing a string field can turn off the display of a text variable. My workaround on that one was to put the numeric field in quotes. Date fields seem now to be a variation on that bug, though quotes don't seem to turn off the bug, as it does for numbers.

Any ideas?

[r4zoli]

What version of OOo and what OS?

[rab212]

It's actually Star Office 8, update 9. OS is WinXP. I do all the reporting on the unix side, though. Solaris server, Java CDE environment.

Do you happen to know if the way that date fields are handled changed in the latest update? I knew how to work around the numeric bug, but I could swear that I had reports I had done months ago that had date fields and no problems, and now the display has turned wonky. Again, I use Report Wizard, not Report Builder.

[r4zoli]

I just checked OOo issue list and can not find bug similar to yours.
OOo 2.3.1 is a version on which SO8 U9 based.
I'm not understood which way you connect reports through SDBC, JDBC or ODBC your database?

[rab212]

Sorry, this is getting a little over my head here, but...A programmer writes a script in R to extract data, which wind up as simple psv files in a unix directory. I point the Report Wizard right at the psv files.

I remember from postings last fall that there has been documentation of the numeric bug - a number field trailing a string field will cause the text to display as zero. Is that still documented? The way dates are getting handled seems to be a variation on that.

Thanks for working with me on this.

[r4zoli]

I'm not familiar with psv file format, it is a text file? Or it a csv file?

Report wizard under documented and I not use it daily.

Best thing what I can suggest go to SUN get help for SO8 if you have a support plan, or go to the script developer.

[rab212]

We use csv files (pipe delimited). Thanks for trying.

[r4zoli]

I just checked OOo issue list and find a bug with csv files and date/time fields.
The problem not in report wizard, but in the csv file handling, and it cause problems in report.
The issue 84247, have example documents, and I tried them in OOo 2.4RC6 and not shown errors. I think the next edition of OOo, 2.4 will be out within a week, and SO8 update 10 in the same time frame. I will check the 2.3.1 version later.

Edit: I checked 2.3.1 and it has the bug written in the issue.

[rab212]

So the new releases, OOo 2.4, and SO8 Update 10, should fix that bug. That's great news - we've had to do a lot of manipulating of variable coding over the last 5 months to get our displays right.

Last question: I read through the issue log that you so kindly supplied, and didn't see mention of a straight numeric field causing the exact same error, but I've encountered that as well. (Time and date are mentioned.) Do you suspect that this fix will cover numeric fields as well?

[r4zoli]

I checked files in issue, and in one string column switch off in 2.3.1, and good in 2.4RC. I think the numbers is same.

Edit: I created a csv file with integers and dates and found broken in 2.3.1 (subtracted 2 from all numbers) and right in 2.4. Next version will solve your problems.

[rab212]

Thanks so much for your help - it's very appreciated!

[ggemmill]

I'm not sure that the bug has been solved completely. Using OO2.4 under Mandriva 2008.0.
I imported a tab-separated file into Writer, deleted some lines and converted text to table. The table was then selected and pasted into a Calc spreadsheet.
The original tab-separated file had MM/DD/YYYY format dates. The resulting spreadsheet displayed and treated dates in two ways: If DD is less than 13, the date was displayed as MM/DD/YY, and could be operated on correctly. If greater than 12, the date was displayed as MM/DD/YYYY, and did not behave correctly. Attachments show this clearly (the formula is =TEXT($A2;"YYYY-MM-DD"),
PS the Find and replace function mentioned earlier saved my bacon with converting MM/DD dates to DD/MM format!

[Villeroy]

All your dates are interpreted as DD/MM/YY, so months >12 are no numbers at all (value 0 => 1899-12-30) and the numbers are wrong (04/08/08 => 2008-08-04)
I convert the Writer table back to tab-delimited text and paste-special as unformatted text into Calc, choose format "US English" for the first 3 columns and apply my preferred date format to the resulting numbers. Formatting the target cells before paste-special unformatted text works as well.

All csv import into Base should use ISO dates to enshure proper text-to-date conversion. When importing csv into spreadsheet dates can be adjusted.