Description: Hello, Some of the Turkish date formats in LibreOffice are not correct or obsolete. Correct selections can be found below: 31.12.99 31.12.99 Cum (short name of the day version) 31.12.99 Cuma 31.12.1999 31.12.1999 Cum (short name of the day version) 31.12.1999 Cuma 31 Ara 1999 31 Aralık 1999 31 Ara 1999 Cum (short name of the day version) 31 Aralık 1999 Cuma 31/12/99 Cum (short name of the day version) 31/12/99 Cuma 31/12/1999 Cum (short name of the day version) 31/12/1999 Cuma 31-12 31-12-99 31-12-1999 12.99 12.1999 Ara 99 Aralık 1999 31.12.99 13:30 31.12.99 13:30:33 31.12.1999 13:30 31.12.1999 13:30:33 I didn't bother to list the wrong or the obsolete ones, that would be great if current ones could be replaced with the above ones. Thank you in advance! Steps to Reproduce: 1.Open LibreOffice Calc 2.Go to Cell Formatting 3.Select Date Actual Results: See attachment Expected Results: See above Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Created attachment 134548 [details] Cell Formatting Window
@Eike, do you have any clue here ?
@Emir, It makes sense to me that your suggestions but do you have any information about TS ISO 8601 standard[1](have to pay money to read(!)) LibreOffice seems using that. [1] https://intweb.tse.org.tr/standard/standard/Standard.aspx?081118051115108051104119110104055047105102120088111043113104073102054076051108099120065070065079
All used date formats are defined in our tr-TR locale data, ie. i18npool/source/localedata/data/tr_TR.xml (or https://cgit.freedesktop.org/libreoffice/core/tree/i18npool/source/localedata/data/tr_TR.xml for browsers). If that needs changes then patches are welcome. Note that there is some documentation in i18npool/source/localedata/data/locale.dtd (or https://cgit.freedesktop.org/libreoffice/core/tree/i18npool/source/localedata/data/locale.dtd fwiw) about specific formats that need to be present. It's not clear to me how ISO 8601 comes into play here (every locale also supports ISO 8601 date formats, regardless of any localized ones), but some public information about that can be found under http://erack.de/bookmarks/D.html#ISO_8601_Date___Time_Representation Formats like 31-12 31-12-99 31-12-1999 may be problematic if input is expected to be parsed in that format (ie. with date acceptance patterns D-M and D-M-Y), which may not properly work because of the ambiguity with ISO 8601 M-D and Y-M-D for days <= 12 and years <= 31
@Gülşah, thanks for the reminder about the standard, I had no idea about that, if only I could read and update my suggestion accordingly (anyone has spare 84 Euro?). Other than that, I haven't encountered most of these date formats LibreOffice has for the TR localisation anywhere in the wild, so I just tried to simplfy them a bit, and MS Office has these anyway. Current options like <name of the day><space><date> or <name of the day><period><date><period><blabla> mostly seem like a direct translation from the English strings. @Eike, XX-XX-XX format is not a necessity, it wouldn't do any harm to omit that, I included it as just another option.
Created attachment 139864 [details] DD and MM changed in places The same error is in Polish localization. I've just attached file with screen-shot.
(In reply to Krzysztof Walczewski from comment #6) > The same error is in Polish localization. I've just attached file with > screen-shot. The dialog's 30-12-1899 date is completely unrelated, that is a translated string of sc/uiconfig/scalc/ui/optcalculatepage.ui For the date values in row 4 of your spreadsheet these look like they are formatted differently as YYYY.DD.MM and you see 2018-02-05 14:32:55 in the input line because for pl-PL the date+time edit format is defined as YYYY-MM-DD HH:MM:SS Anyway, please don't mix unrelated locales' problems into one bug.
@Eike, reading your comment 4 I understand the current behaviour is correct, isn't it? Should we close this as RESOLVED NOTABUG?
Closing as RESOLVED NOTABUG...