Extraction API - Date control returns localized format string

[elzody]

Is your feature request related to a problem?

With the new form control extraction / filling API, it seems the Date type needs some extra work. If you have a document with a date form control, it might return something like this:

"ContentControls.ByIndex.2": {
      "id": 266140418,
      "tag": "",
      "alias": "birthday",
      "content": "13. Dezember 2024",
      "type": "date",
      "DateFormat": "T. MMMM JJJJ",
      "DateLanguage": "de-DE"
    }

The DateFormat property returns a localized, arbitrary format string which is almost impossible to use. It would be better to use ISO-standard format string tokens in a format such as "DD.MM.YYYY" instead of something like "TT.MM.JJJJ" so that consistent formatting can be applied to the date -- with these non-standard tokens, many libraries cannot account for this and do not know how to correctly format the date, and it would be impossible to account for them all.

Describe the solution you'd like

One solution for this is to provide an ISO compliant format string using the expected tokens, or to just store the given date as a Unix timestamp and let applications display the date in their preferred format.

cc @aszucs3

[juliusknorr]

Most common would probably be to use ISO 8601. Also something @eszkadev brought up is that the convert-to endpoints have a parameter so that the api consumer can pass the wanted locale, which would also be good to have here so when transforming a document the actual format used in the file can still be influenced.

[aszucs3]

i made something about it here: https://gerrit.libreoffice.org/c/core/+/172849/

In extract side added a new extracted data: "CurrentDate": "2024-07-17T00:00:00Z" i think it will always be ISO 8601 format

For transform side i added a new "date" data.. that require YYYY-MM-DD input to work, and it will set the date value of the date content control. (IT will not change the string displayed there!) "content" sets only the displayed string of the content control.. and unfortunatelly they can differ from each other.. So now, we should set both of them at once .. like this: "ContentControls.ByIndex.6": { "date":"2024-03-22", "content": "7/17/2024" }

I was thought what to do about it.. i bet the best way would be if user would require to set only "date" and then that would set "content" as well with a converted date format... but it is not easy to convert date to the required format at that point of code... i mean.. even if i do it.. i will afraid that it may miss in some special cases... If it is important.. i can try to do it ... maybe i could come up with some cleaver hack (if i can reach dialog codes)... but if it is not so important, then i would leave it as it is now.

So now, i just implemented the easyest way...: user can set "date" and "content" separatelly.. and user can convert it manually and set that value to "content".. or just set the same value to "content" as to "date" ...

I could easily imlement an other way.. if user set "date" it could automatically set the same string to "content" ... to get the same result as this: "date":"2024-03-22", "content": "2024-03-22" but it may could confuse some cases when user want to set converted date to "content".

[elzody]

@aszucs3 Thanks a lot for working on this. I think that's a fine way of handling it. All that was really needed is a standardized format like ISO 8601 for the dates, instead of the arbitrary localized ones. Those were impossible to work with correctly, but with the ISO formatting, we can properly convert them as needed and handle them properly.

[hfiguiere]

We should use RFC 3339 date which is just a profile (subset) of the ISO format that is more accessible.

But on overall any text transmission of a date should be done using that standard.