Puede haber algún impacto, ya que difieren en los órdenes de clasificación, las relaciones entre mayúsculas y minúsculas, los órdenes de clasificación, los separadores de miles, el símbolo de moneda predeterminado y más.
C.utf8 =configuración regional predeterminada compatible con los estándares POSIX. Solo son válidos los caracteres ASCII estrictos, ampliados para permitir el uso básico de UTF-8
en_US.utf8 =Configuración regional UTF-8 de inglés americano.
Aunque no estoy seguro del efecto específico que podría encontrar, creo que puede establecer la configuración regional y la codificación dentro de su aplicación si es necesario.
Aquí hay algunas razones por las que agregué LC_TIME=C.UTF-8 en /etc/default/locale , en caso de que ayude a alguien:
Proporciona un reloj de 24 horas en lugar de AM/PM en Firefox para HTML5 input type=time (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time) y usa un selector de fecha en el formato DD/MM/YYYY en lugar de MM/DD/YYYY para tipo de entrada HTML5=fecha (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date).
Permite utilizar el formato de fecha internacional AAAA-MM-DD (ISO 8601) con un reloj de 24 horas al responder correos electrónicos en Thunberbird.
Anteriormente, era posible con LC_TIME=en_DK.UTF-8 (http://kb.mozillazine.org/Date_display_format) pero actualmente hay un error y dejó de funcionar (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c155).
Editar:ahora incluso el LC_TIME=C.UTF-8 la solución alternativa no funciona para Thunberbird (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c197) pero al menos en_IE.UTF-8 proporciona el formato de fecha europeo DD/MM/AAAA en lugar de MM/DD/AAAA.
En general C es para computadora, en_US es para personas en EE. UU. que hablan inglés (y otras personas que desean el mismo comportamiento).
El para ordenador significa que las cadenas en algún momento están más estandarizadas (pero aún en inglés), por lo que la salida de un programa podría leerse desde otro programa. Con en_US , las cadenas podrían mejorarse, el orden alfabético podría mejorarse (tal vez por las nuevas reglas de estilo de Chicago, etc.). Por lo tanto, más fácil de usar, pero posiblemente menos estable. Nota:los locales no son solo para la traducción de cadenas, sino también para la intercalación (orden alfabético, números (por ejemplo, separador de miles), moneda (creo que es seguro predecir que quedarán $ y 2 dígitos decimales), meses, día de las semanas , etc.
En su caso, es solo la versión UTF-8 de ambas configuraciones regionales.
En general, no debería importar. Por lo general, prefiero en_US.UTF-8, pero generalmente no importa, y en su caso (aplicación de servidor), solo debería cambiar el registro y los mensajes de error (si usa locale.setlocale() . Debe manejar las configuraciones regionales del cliente dentro de su aplicación. Los programas que leen de otros programas deben establecer C antes de abrir la tubería, por lo que realmente no debería importar.
Como ves, probablemente no importe. También puede usar POSIX locale, también definido en Debian. Obtiene la lista de configuraciones regionales instaladas con locale -a .
Nota:la microoptimización prescribirá C /C.UTF-8 locale:sin traducción de archivos (gettext ) y reglas simples sobre la intercalación y el formato de números, pero esto debería ser visible solo en el lado del servidor.