target, confirm, send to the right developer

accepting

fs->sab: There seems to be a problem with the SvXMLNumFormatContext.

We export the date format of the control as number style. The format
string for the chose format ("standard (long)") is "NNNNT. MMMM JJJJ",
with locale "de-DE". This is what is what we write upon export. In the
content.xml, this arrives as:
  <number:date-style style:name="C5038" style:family="data-style"
      number:language="de" number:country="DE"
      number:automatic-order="true" number:format-source="language">
   <number:day-of-week number:style="long"/>
   <number:text>, </number:text>
   <number:day number:style="long"/>
   <number:text>. </number:text>
   <number:month number:style="long" number:textual="true"/>
   <number:text> </number:text>
   <number:year number:style="long"/>
  </number:date-style>

When reading the document, a SvXMLNumFormatContext is created for this
tag. We now ask the context for the format string (method GetFormat),
and what it returns is "NNNNTT. MMMM JJJJ" (note the additional 'T'!).
Since our date control does not support this format, it falls back to
the default (standard short).

To me, the problem seems to be that the GetFormat returns a wrong
format string - the XML representation of "NNNNTT. MMMM JJJJ" would
have been:
  <number:date-style style:name="C5038" style:family="data-style"
      number:language="de" number:country="DE">
    .
    . (same as above)
    .
  </number:date-style>

Note the missing "automatic-order" and "format-source" attributes.
So in my opinion, the SvXMLNumFormatContext::GetFormat doesn't respect
the "automatic-order" and/or "format-source" attributes.

Hi Niklas,

please have a look at this.

Thanks Sascha

Sascha, the handling of "automatic-order" and "format-source" is in
SvXMLNumFormatContext::CreateAndInsert, but not in
SvXMLNumFormatContext::GetFormat. SvXMLNumFormatContext::GetFormat is
something between you and Frank. I have never touched that method and
don't know if it can be changed there without breaking something else.

Set to 1.1.2 because of developer limit

ok, I take it and will have a look on it.

I noticed a simlar effect for the formatted control: When you set a certain date
format, then this format is also lost/changed upon reloading the document. In
particular, the following date formats (in a german notation :) are affected:

NNNNT. MMMM JJJJ
TT.MM.JJ
T. MMMM JJJJ
TT.MM.JJ HH:MM

To me it seems as if this is the same bug, since these formats also use the XML
attributes which GetFormat ignores. So, when this bug is fixed, we should also
verify that the formatted control works properly with all date formats then.

change subcomponent to 'none'

retarget to OOo 2.0 as agreed with sab , fs , msc.

*** Issue 28732 has been marked as a duplicate of this issue. ***

changing summary from
  another form datefield problem
to
  cannot save certain date formats in form controls

to better reflect what this is about (and perhaps to prevent duplicates)

argh. Now really.

Just to let you know I have a user who never wants to use OOo again because of
this bug. Please raise priority to 9.

Yes, we are sick of US format dates, US paper, and settings that don't stick.

This is probably related (or if not I can submit an new issue if you prefer)

(OOo 1.9.71) Using the short date format, if both values for DD & MM are lower 
than 12, they are reversed as soon as the current row/record is saved or loses 
focus. So for eg 8th Sept becomes 9th Aug. Where the day is greater than 12, 
it comes out normally. This makes entering dates very unreliable. 

BTW in Australia we use DD MM YY instead of MM DD YY as in the USA, which 
might have soemthing to do with it.

Davgid Bell

fixed

please verify

re-open issue and try to reassign to fst@openoffice.org

try to reassign to fst@openoffice.org

try to reset resolution to FIXED

Found fixed on cws Calc30 using Windows and Linux version to test

found integrated on master src680m89