Created attachment 46197 [details]
date field problem test file

Reassigned to ES.

rbircher -> torwart

Pleas have a look on this issue. Thanks!

Hi Eric, 

I think the issue is that the internal date number is stored in the user field
instead of the real date value i.e. if you input 11.02.07 (MMDDYY) the value
stored is 39388.
Tested on OOoDev300_m26FR and Ubuntu 8.4

Steps to simply reproduce: 
Ctrl+F2, variables tab, select User Field
Name it UF1 value  11.02.07
Format as date MMMM J AAAA
Click on the green mark to validate the format
Insert the field --> date is correctly inserted and formatted

Without closing the dialog
Click on Input field, UF1 is selected under Selection area
Click on Insert
The "internal" date number is shown : 39388
Click ok without changing anything --> this number 39388 is inserted

Click again on Input Field and enter a value as a date formatted MMDDYY
Both Input Fields will have the date you just enter, but formatted as you enter
them.
The User Field will now display December 30 1899

I let it as unconfirmed because I'm not sure that it's not another issue than
the one described here. For me it's the same because of the original storage of
the date number, but I may be wrong :)
Kind regards - Sophie

add me in cc

Upon my failure to replicate this specific report, I decided to make a document where I inputted the original UF1 input twice on different lines and a UF2 input  twice on different lines in the same document. UF2 was in the format of D MMMM YYYY and upon saving and closing o the document, the UF1 inputs were the same as 11.02.07; however, my date of 8 12 1997 for the UF2 [ D MMMM YYYY format ] both returned as only 1997. This although, a different instance of this bug, confirms that there is a preservation of data issue within OpenOffice and needs to be looked into.

(In reply to comment #6)
> Upon my failure to replicate this specific report, I decided to make a
> document where I inputted the original UF1 input twice on different lines
> and a UF2 input  twice on different lines in the same document. UF2 was in
> the format of D MMMM YYYY and upon saving and closing o the document, the
> UF1 inputs were the same as 11.02.07; however, my date of 8 12 1997 for the
> UF2 [ D MMMM YYYY format ] both returned as only 1997. This although, a
> different instance of this bug, confirms that there is a preservation of
> data issue within OpenOffice and needs to be looked into.

This was tested on Windows 7 OS SP1

(In reply to comment #7)
> (In reply to comment #6)
> > Upon my failure to replicate this specific report, I decided to make a
> > document where I inputted the original UF1 input twice on different lines
> > and a UF2 input  twice on different lines in the same document. UF2 was in
> > the format of D MMMM YYYY and upon saving and closing o the document, the
> > UF1 inputs were the same as 11.02.07; however, my date of 8 12 1997 for the
> > UF2 [ D MMMM YYYY format ] both returned as only 1997. This although, a
> > different instance of this bug, confirms that there is a preservation of
> > data issue within OpenOffice and needs to be looked into.
> 
> This was tested on Windows 7 OS SP1 in version OOo 3.4.1

Entering 39554 for the input displays the 'correct' date assuming no parsing. Shouldn't it not know what to do on that input for MMDDYY? Also 395541 is December 13'th 2982... Using Windows 7 OS. The problem may be in the parsing of the input field (or lack of)

Also I was able to replicate the bug as originally seen in the reproduce steps.

10.11.12 is being saved as 0.12 as well as 10.11.1200
Jan102012 gets saved as 0 and 
RAWR! is saved as 0 RAWR!! and RAWR!!!! are saved as 1

(In reply to comment #10)
> Also I was able to replicate the bug as originally seen in the reproduce
> steps.

I also was able to replicate the report of the original reproduction steps; however, tried to replicate the more in-depth tests from the second report as to try and further the testing of this particular bug.

Sorry for the earlier non-sense. Here is some clarification. Hope it helps.

OS used: Windows 7 Professional
Open Office build used: 9593

Following the OP's reproduce steps, I was able to recreate the bug as he described.

Using the attachment 46197 [details] in comment 2 I did these experiments. Note that the results are the same for all 3 fields.

Input: 10/10/10
No update to following line. Even after save and reopen.
After save, close, and reopen; the input field becomes 0.1
Note 10/10 = 1; 1/10 = 0.1;

Input: 10/10/1000
No update to following line. Even after save and reopen.
After save, close, and reopen; the input field becomes 0.001
Note 10/10 = 1; 1/1000 = 0.001;

Input: 101010
The following line after the input line immediately updates to July 20, 2176
After save, close, and reopen; the input field is still 101010

Input: 25*4
The following line after the input line immediately updates to April 9, 1900
After save, close, and reopen; the input field becomes  100
Note 25*4 = 100

Input: 500/5
The following line after the input line immediately updates to April 9, 1900
After save, close, and reopen; the input field becomes  100
Note 500/5 = 100

For a formatted input field, these results are completely unexpected and in the case of the first two inputs tested, completely different from what the user defined.

Reset assignee on issues not touched by assignee in more than 2000 days.

As given in description.

Rev. 1522537 Debian