Date position into cell

[afshin]

Hello.

Insert → Date (Ctrl+;) → Ctrl+1
and then I select Date Category and اسفند۳۱ Format, but into preview box shows ۳بهمن
While بهمن۳ should be shown, that is, first the day and then the name of the month should be shown.

How can fix this? Is this a bug or not?

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 60(Build:1)
CPU threads: 2; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: fa-IR (en_US.UTF-8); UI: en-US
Ubuntu package version: 4:7.6.2~rc1-0ubuntu0.22.04.1~lo1
Calc: threaded

[karolus]

Hallo

Format Code [NatNum12 D=ordinal]MMMM D shows بهمن سومین for me, is that correct??

[afshin]

Correct is:

۳بهمن

What I mean is that first the number ۳ should be displayed on the right side of the cell and then the name of the month (بهمن).

[karolus]

Cannot help here, maybe a bug with RTL-locales?

[Lupp]

Well, format codes are LTR supposedly and the given example shows western/English code names (M, D). By that a conflict is surely introduced.
Might [NatNum1][~persian]MMM D help? Probably you want to replace the “Western” space by a farsi or Arabic variant. The [~persian] should be superfluous ikn a Persian locale.
BTW: I assume the example date is 2023-11-03. ISO 8601 provides still the only “format” to communicate dates globally in an unambguous way.

[erAck]

@afshin

first the number ۳ should be displayed on the right side of the cell and then the name of the month (بهمن)

So it’s only that for [NatNum1]D MMM the preview in the dialog is wrong, but the final cell display is correct, as in the image? Likely the preview is not fully RTL aware.


Edit: tried in fa-IR locale with CTL enabled in a RTL sheet, and also the cell display is not as expected. However, it works correctly in ar-DZ locale, so it looks like a Farsi specific bug, please submit a bug and report the resulting bug number in the form tdf#123456 back here. Thanks.

@Lupp

Might [NatNum1][~persian]MMM D help?

That’s not how it is supposed to work. The logical display direction of a LTR format code depends on context and in a RTL script output should be displayed RTL.

[Lupp]

This is mined terrain to me. (You may even remember the reason.)
And I can’t even see clearly with the help of Wikipedia whether ordinary decimal numbers in RTL fonts usually start (on the right) with the LeastSignificantDigit. That’s what it looks like in my experiments.

I’m out so far, but would still like to see a specification. Probably a “native RTL person” among the developers can help.

[erAck]

In RTL context, numbers in Arabic (“European” ASCII) digits (or any sequence of Latin or other LTR script characters for that matter) are still displayed (and cursor-travelled) LTR as usual, but the position of that sequence should be in the RTL direction. However, here we have Arabic-Indic digits, so no direction switching should occur. The format code D MMM in this example produces the physical string / character sequence {U+06F3,U+0020,U+0628,U+0647,U+0645,U+0646} and it’s up to the output rendering to display that in proper RTL logical context. i.e. the expression

=TEXT(DATE(2023;11;3);"[NatNum1]D MMM")

in fa-IR locale results in ۳ بهمن with

Character	Unicode
۳	U+06F3
	U+0020
ب	U+0628
ه	U+0647
م	U+0645
ن	U+0646

whereas in ar-DZ locale it is ٣ نوفمبر with

Character	Unicode
٣	U+0663
	U+0020
ن	U+0646
و	U+0648
ف	U+0641
م	U+0645
ب	U+0628
ر	U+0631

Characters as =MID(A$1;B2;1), =MID(A$1;B3;1), … and Unicode as ="U+"&BASE(UNICODE(C2);16;4), ="U+"&BASE(UNICODE(C3);16;4), …


A difference is that fa-IR uses ۳ U+06F3 EXTENDED ARABIC-INDIC DIGIT THREE, while ar-DZ uses ٣ U+0663 ARABIC-INDIC DIGIT THREE; maybe those have different BiDi properties, but maybe also the characters used in month names, didn’t look it up. That would have to be investigated if the bug was filed…

[Lupp]

@Lupp

… And I can’t even see clearly with the help of Wikipedia whether ordinary decimal numbers in RTL fonts usually start (on the right) with the LeastSignificantDigit. That’s what it looks like in my experiments.

Yes. This is off topic here, but not quite out of context.
After all the D in the format code for dates also may have to display two (NatNum) digits regarding the locale if needed.

[afshin]

The bug is reported here:
https://bugs.documentfoundation.org/show_bug.cgi?id=158064