I concede that you are right. On my test system the locale was configured for
LANG=en_US.utf8 and LC_TIME=en_DK.utf8. Changing the LC_TIME did not affect the
cell's number format, but changing LANG did. To clarify: when entering
"YYYY-MM-DD" into a cell, the formatting of the cell for both display and for
inline editing became that associated with LANG: "DD/MM/YY" for en_US and
"DD/MM/YY" for he_IL. The formula bar showed YYYY in place of YY.
Therefore, one issue is that OOo is using LANG for setting time, not using
LC_TIME. I will search for a bug on that and report it if necessary.
> It takes the locale from the
> cell's number format, which by default is the system locale, and then
> uses that locale's date-editing format, as defined in our list of
> locale data.
Our list? Where is that list? Why isn't LC_TIME being used for this?
> As indicated by the summary, this issue is only about special treatment
> for ISO 8601 format.
This is in fact the format that I am interested in. Quick experimenting in Calc
shows that only the Hungarian and Lithuanian locales in OOo use the YYYY-MM-DD
format, and they both suffer from other issues where I would not use them. I
suppose that a dedicated ISO 8601 locale would be a workaround, but the fix
would involve (as I see it) using LC_TIME for the editing format.
> Editing does not default to US format.
I concede that you are right. On my test system the locale was configured for
LANG=en_US.utf8 and LC_TIME=en_DK.utf8. Changing the LC_TIME did not affect the
cell's number format, but changing LANG did. To clarify: when entering
"YYYY-MM-DD" into a cell, the formatting of the cell for both display and for
inline editing became that associated with LANG: "DD/MM/YY" for en_US and
"DD/MM/YY" for he_IL. The formula bar showed YYYY in place of YY.
Therefore, one issue is that OOo is using LANG for setting time, not using
LC_TIME. I will search for a bug on that and report it if necessary.
> It takes the locale from the
> cell's number format, which by default is the system locale, and then
> uses that locale's date-editing format, as defined in our list of
> locale data.
Our list? Where is that list? Why isn't LC_TIME being used for this?
> As indicated by the summary, this issue is only about special treatment
> for ISO 8601 format.
This is in fact the format that I am interested in. Quick experimenting in Calc
shows that only the Hungarian and Lithuanian locales in OOo use the YYYY-MM-DD
format, and they both suffer from other issues where I would not use them. I
suppose that a dedicated ISO 8601 locale would be a workaround, but the fix
would involve (as I see it) using LC_TIME for the editing format.
Thanks.