Hi, Jan Stary wrote on Tue, Jun 22, 2021 at 11:24:15AM +0200: > On Jun 20 18:58:31, ffuen...@texto-plano.xyz wrote:
>> I speak Spanish and thus I use a locale called es_CL.UTF-8. XFCE is fine >> with it. However, my date is expressed directly as it comes from date(1). >> This is confirmed by their docs >> https://docs.xfce.org/xfce/xfce4-panel/4.16/clock so how do I make date to >> work with my language. >> >> This is my locale: >> >> LANG=es_CL.UTF-8 >> LC_COLLATE="es_CL.UTF-8" >> LC_CTYPE="es_CL.UTF-8" >> LC_MONETARY="es_CL.UTF-8" >> LC_NUMERIC="es_CL.UTF-8" >> LC_TIME="es_CL.UTF-8" >> LC_MESSAGES="es_CL.UTF-8" >> LC_ALL=es_CL.UTF-8 > man locale > > Programs in the OpenBSD base system ignore the locale except > for the character encoding, and it is not recommended to > use any of these variables except that the following > non-default setting is supported as an option: > > export LC_CTYPE=en_US.UTF-8 > > OpenBSD's date(1) ignores your locale setting. That's the correct answer, and there are no plans to change that in the future. The reason is that we prioritize simplicity and maintainablity of the C library, and consequently correctness and security, over localization of base system facilities. On top of that, even if you do not take the horrible complication of the library code that LC_* support would imply into account, LC_* also poses some security risks from the user perspective, in particular in system administration and maintenance contexts. Predicatbility of output, and consistent parsing of input, is more valuable for low-level work than localization. Perspectives may vary, but my personal opinion is that adding all those LC_* variables to POSIX was a mistake. The C library is not a reasonable place to handle higly specialized and highly complicated topics like localization. They belong into specialized programs like typesettung software, UI libraries and the like, not into a general-purpose operating system. In general, we try to follow POSIX because standardization and portability have significant advantages. But there are limits. If standards requirements are too bad, we may decide to ignore them in some (rare) cases. Hence, on OpenBSD, you can rely on predictable output from strftime(3) and on predictable parsing by strptime(3). All this is mostly documented, for example: STRFTIME(3) Library Functions Manual [...] CAVEATS On systems other than OpenBSD, the LC_TIME locale(1) category can cause erratic output; see CAVEATS in setlocale(3) for details. SETLOCALE(3) Library Functions Manual [...] CAVEATS On systems other than OpenBSD, calling setlocale() or uselocale(3) with a category other than LC_CTYPE can cause erratic behaviour of many library functions. For security reasons, make sure that portable programs only use LC_CTYPE. For example, the following functions may be affected. The list is probably incomplete. For example, additional library functions may be impacted if they directly or indirectly call affected functions, or if they attempt to imitate aspects of their behaviour. Functions that are not standardized may be affected too. LC_COLLATE glob(3), strcoll(3), strxfrm(3), wcscoll(3), wcsxfrm(3), and the functions documented in regexec(3) LC_MESSAGES catgets(3), catopen(3), nl_langinfo(3), perror(3), psignal(3), strerror(3), strsignal(3), and the functions documented in err(3) LC_MONETARY localeconv(3), nl_langinfo(3), strfmon() LC_NUMERIC atof(3), localeconv(3), nl_langinfo(3), strfmon(), and the functions documented in printf(3), scanf(3), strtod(3), wcstod(3), wprintf(3), wscanf(3). This category is particularly dangerous because it can cause bugs in the parsing and formatting of numbers, for example failures to recognize or properly write decimal points. LC_TIME getdate(), nl_langinfo(3), strftime(3), strptime(3). Similarly, this is prone to causing bugs in the parsing and formatting of date strings. LC_CTYPE On systems other than OpenBSD, this category may affect the behaviour of additional functions, for example: btowc(3), isalnum(3), isalpha(3), isblank(3), iscntrl(3), isdigit(3), isgraph(3), islower(3), isprint(3), ispunct(3), isspace(3), isupper(3), isxdigit(3), mbsinit(3), strcasecmp(3), strcoll(3), strxfrm(3), tolower(3), toupper(3), vis(3), wcscoll(3), wcsxfrm(3), wctob(3) Yours, Ingo
