[Libreoffice-bugs] [Bug 116579] Date format setting not recognised

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Thu Apr 26 23:46:28 UTC 2018


https://bugs.documentfoundation.org/show_bug.cgi?id=116579

--- Comment #9 from Gerhard Weydt <gerhard.weydt at t-online.de> ---
Hi Elmar,

I've spent a lot of time to figure out what you really want to achieve, and it
becomes ever more nebulous.

It starts with your statement "should convert 18-3-23 to date format". This
already poses some questions:
You state in your example files that y-m-d is the standard format for South
Africa, so why would you expect a conversion?
What do you mean by "... to date format"? Do you wish to have another date
format? Which?
Wikipeda says
(https://en.wikipedia.org/wiki/Date_and_time_notation_in_South_Africa) that
South Africa has accepted the ISO standard, which means that dates can/should
be written as YYYY-MM-DD, but that  d/m/y is still commonly used (so how can
you say that y-m-d is the standard format?); and it seems that LibreOffice
still uses this "old" format as its default for South Africa, according to my
tests. It's the same in Germany: ISO is the standard since at least 18 years (I
delved into the matter when I managed the year 2000 project in my company), but
still nowadays people rarely use the ISO representation. So I think the default
date format d/m/y used in LibO is the best choice as user friendliness is
concerned, although I would wish for using the ISO date for principal reasons.

Date handling is a very complex problem, and I can't say that I understand all
its ramifications. But I think that in LibO these rules apply:
1. there is a standard date representation used, for which I do not know where
to find the definition. For South Africa it seems to be y/m/d which does not
fit  the wikipedia statement: if I add y.m.d. as date acceptance pattern, a
given date 1.2.3 will be converted to 1/2/3.
2. The date acceptance patterns define which string representations will be
interpreted as dates and consequently be converted to the standard date
representation for this locale. My test y.m.d, using a german style for a date,
is an example.
3. Entries similar to ISO dates are treated as those: 18-3-4 is converted to a
correct ISO format 2018-03-04, and they are not converted to the standard
format used in 1.

I think this is the best one could do, viewing that ISO is a standard accepted
in these countries (I never looked into the situation of a country that had not
accepted ISO), but common usage is different: present dates in the format
commonly used, but retain a (standardised) format for entries in ISO-conforming
format, for then it is assumed that the user intentionally uses this format.

I hope this makes matters clearer for you. I have the suspicion that you wish
LibO to perform some conversion of dates which you do not exactly know how to
specify, but I cannot guess which.

The comments in your documents:
Col B is as as input
Col C shows how I input the info (without the <>)
are a problem for me (and probably for many people), because you use "input" in
both cases, whereas I assume that one column (B) is the result of the input
after the standard conversion by Calc.

Consider these remarks, and if you still think there's something wrong with
LibreOffice, provide precise informatiuon.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20180426/db86d506/attachment-0001.html>


More information about the Libreoffice-bugs mailing list