Solución:
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).
los para computadora 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 mediante nuevas reglas de estilo de Chicago, etc.). Por lo tanto, más fácil de usar, pero posiblemente menos estable. Nota: las configuraciones regionales 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 permanecerá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 configurar C antes de abrir la tubería, por lo que realmente no debería importar.
Como ves, probablemente no importe. También puede utilizar POSIX locale, también defina en Debian. Obtienes 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 clasificación y el formato de números, pero esto debería ser visible solo en el lado del servidor.
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 / AAAA en lugar de MM / DD / AAAA para HTML5 tipo de entrada = 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 hay un error actualmente y dejó de funcionar (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c155).
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 puede encontrar, creo que puede establecer la configuración regional y la codificación dentro de su aplicación si es necesario.