How to format a date field in a different language in a MS Word document?

[riabenko]

The date fields appear to inherit the paragraph language by default. It is possible to customise the date into a different language as follows.

1. Double-click the field to open “Edit Fields” dialogue.
2. In the “Format” panel choose the last option, which is “Additional formats…”, to open “Format Number” dialogue.
3. Select the language in the “Language” drop-down menu.

This seems to be preserved if the document is saved as an ODF. However, if the document is saved as DOCX, it defaults back to the paragraph locale on the file re-opening.

Here is an example from a signature block of a document.

Date: / Дата: 09 April 2026 / 09 квітня 2026 р.

This reverts to the following, which is not expected.

Date: / Дата: 09 April 2026 / 09 April 2026 р.

Is the issue inherent to the DOCX file format and cannot be solved? Or can it be solved somehow? Is it a bug that needs to be reported?

Here is the technical data about the installation in case it may be relevant.

Version: 25.2.5.2 (X86_64) / LibreOffice Community
Build ID: 520(Build:2)
CPU threads: 4; OS: Linux 6.18; UI render: default; VCL: gtk3
Locale: uk-UA (uk_UA.UTF-8); UI: en-US
Calc: threaded

[Lupp]

(Spoken aside.)

I would suggest to thoroughly consider:

1. Is a TextField the appropriate way to insert a date-time?

• Concerning variable (updating) TextField: There is no reasonable way to get the functionality without either a TextField or lots of UserCode.
  However, I can hardly imagine a realistic use-case.

• Concerning fixed date and/or time code inserting the values directly as ordinary text is more recommendable.

2. Is it reasonable to use locales (regional preferences) for the presentation of dates and TOD values?

• Yes, but only if you want to create confusion.

• No!!!
  It’s a shame that office software doesn’t take into account the fact that most documents these days are not local in the sense of being relevant only to a small region and a small number of people.

• Questions about related issues in forums or in this Q&A site are posted again and again, and contributors have already wasted thousands of hours to answer them, and possibly to show workarounds.

3, What should be recommended and well supported?

• Exclusive use of ISO 8601 complyant date-time representation.
• The delimiting T between date an time may be replaced by a space to get better readability for humans.
• Appending information about the time zone, best as an offset to UTC.

4. Is there such support?

• As already mentioned: Currently no built-in support.
• UserCode is available. See attachment for an example.

trueDateTimeWithUTCoffset.odt (44.8 KB)

[riabenko]

In the use case referred to in the question, the automatically changing date field stands for the date when the document is printed for signing. So, the date is determined by the computer where the document is opened for printing. It is expected that its time and date are configured reasonably enough and it is more reliable than humans.

The time zone is implied by indicating or implying the place of the document, such as in the beginning of the contract, where the city and the country of the document is usually indicated. This often influences what laws may apply to the document, so it is not updated automatically.

When the lawyers complete finalising the draft for signing, they often give up control over the document to other people, such as managers, assistants, clients, notaries etc., who arrange signing on their own. Such executives often click “Print” or “Export to PDF” without paying attention to anything in the document that may need to be updated due to the change of the date of signing. This can be partially mitigated in the text by some legalese, such as “on the day of signing hereof”. However, the date of singing still needs to be indicated somewhere. More often than not, the signatory just skips an empty “date” field, even if I put it next to the “signature” field. The unchecked last minute changes by hand, especially under pressure of a meeting, may result in unnecessary avoidable mistakes, especially when the person is unfamiliar with the document structure.

Due to all this, there is also a style guideline in the department where I work that requires me to put the automatically changing date in place of the document’s date and in the signature block. It sometimes results in nonsensical documents where different dates of signing are indicated right next to each other due to the signing software putting a date next to a digital signature, so I do my best to predict when the document is signed digitally. The formats of the date in English and Ukrainian are also dictated by the style guideline. The guideline was developed based on practice of drafting in MS Word and so far is only expected to be compatible with it.

[Lupp]

Thanks for the explanation.
Your use-case is interesting. I always create a new document in such a case, and print it immediately. (However, my most used letter template also has a fixed-date field in ISO 8601 - but without the UTC offset.) Sorry, I guess I came across as a know-it-all.
(My long comment was mainly made to have it available to point at it in “the next case”.

[keme1]

Writer seems to save language settings correctly, at least when I use a character style to set the language, but it fails to pick up that setting correctly when reopening. When I open the attached docx document - as saved from Writer - in Word, it retains the English and Ukrainian date format respectively. When I reopen in Writer it displays the behaviour you mention.
An odt file saved from the same document (also attached) opens correctly in both Word (M365) and Writer (version 25.8), so for the time being it appears to be better to save using that file format, also when sharing with MS users.
DateStylingTest.docx (11.7 KB)
DateStylingTest.odt (10.1 KB)

I assume that this is a bug in Writer’s input filter for docx. Will update my LO install to latest version and see whether the problem persists, in which case I will submit a bug report (unless someone beats me to it).

[keme1]

Bug report submitted.
https://bugs.documentfoundation.org/show_bug.cgi?id=171694

[keme1]

It turns out that the bug was also reported 4 years ago, in a submission I failed to locate before submitting my own.
In that old entry it is flagged as a bug in export, which is also what my initial problem description indicates, but my tests show that export works fine and this problem arises at docx import, and I have entered info to that effect later in my posting.
I have some problems logging into the bug tracker site ATM to rectify this discrepancy, but will try to convey it when I can. However, as the issue seems to have had little attention for 4 years already, don’t expect a speedy solution.
Log in there and vote for it if you will. Don’t hold your breath in anticipation!

[riabenko]

Thank you for directing me to the report. I added a test file based on my example to it.

[riabenko]

I do not know the full answer but I wanted to share a partial workaround that works for some of my use cases and might be useful for somebody else. The workaround is to split the text into different paragraphs.

Using the example from the question, it could be as follows.

Date: 09 April 2026 /
Дата: 09 квітня 2026 р.