Moment: em, local nos EUA

Existe uma localidade en , ela apenas não vem em um arquivo separado. É amplamente aceito por moment().locale() e moment.locale() :

moment.locale('fr')
"fr"
moment().format("LLLL")
"vendredi 25 novembre 2016 03:39"
moment.locale('en')
"en"
moment().format("LLLL")
"Friday, November 25, 2016 3:39 AM"

en-US também funciona porque buscamos uma correspondência menos específica e o local en é o inglês americano:

moment.locale('en-GB')
"en-gb"
moment().format("LLLL")
"Friday, 25 November 2016 03:40"
moment.locale('en-US')
"en"
moment().format("LLLL")
"Friday, November 25, 2016 3:40 AM"

Eu não acredito; considere o caso em que a localidade é detectada no ambiente e, em seguida, um caminho de depósito de requerimento é construído para carregar o momento / localidade / $ {detectadoLocale}. Se essa variável for "en" ou "en-us", o requirejs falhará ao carregar um arquivo (obtém um 404). Se for detectado como 'de', o arquivo será carregado.

O carregador de locale do @eigood Moment sabe que já está em inglês e não tenta carregá-lo de um arquivo externo.

@icambron Não acho que você esteja certo sobre descer na árvore quando o usuário passa 'en-US' como locale. Na verdade, estou atualmente depurando-o e ele está quebrando porque você NÃO está descendo pela árvore.
Meu caso de uso é que estou chamando moment.utc (myDate, myFormat, locale, true) onde locale é apenas uma única string 'en-US'. Como essa string não pode ser importada (já que não há nenhum arquivo para ela), mas não é uma matriz, ela tenta exigir o local e, em seguida, interrompe os ambientes de produção.
Parece-me que o melhor comportamento real seria realmente incluir en-US na lista de localidades presentes por padrão (não está lá agora, apenas en por conta própria).

@steveccable Bem, ele tenta carregá-lo, apenas no caso de você ter uma localização mais específica. Quando falha, ele tenta apenas "en" e é bem-sucedido. Acho que a desconexão é apenas que de alguma forma a falha ao carregar "en-US" está quebrando para você. Nada deve explodir aqui; ele apenas deve falhar normalmente e passar para a próxima opção. Portanto, você terá que me contar mais sobre seu ambiente: o que, especificamente, está errado?

@icambron Meu ambiente é um aplicativo React Native que usa npm para controlar minhas dependências e consegui replicar a falha mesmo em aplicativos de amostra mínimos. O problema é que na função loadLocale, ele tenta requerer ('./ locale /' + nome) onde nome é en-US, e esse requerimento falha. Quando essa exigência falha em uma versão de lançamento, faz com que o aplicativo trave com um rastreamento de pilha ao longo das linhas a seguir:

E/ReactNativeJS: Requiring unknown module "./locale/en-us".
E/AndroidRuntime: FATAL EXCEPTION: mqt_native_modules
                                                                Process: com.myApp, PID: 30054
                                                                com.facebook.react.common.JavascriptException: Requiring unknown module "./locale/en-US"., stack:
                                                                o<strong i="7">@2</strong>:742
                                                                n<strong i="8">@2</strong>:426
                                                                i<strong i="9">@2</strong>:278
                                                                t<strong i="10">@2</strong>:210
                                                                Xe<strong i="11">@648</strong>:16702
                                                                nt<strong i="12">@648</strong>:17804
                                                                gt<strong i="13">@648</strong>:22583
                                                                yt<strong i="14">@648</strong>:22460
                                                                wt<strong i="15">@648</strong>:23200
                                                                c<strong i="16">@648</strong>:1112
                                                                parse<strong i="17">@645</strong>:1536
                                                                render<strong i="18">@643</strong>:2923
                                                                _renderValidatedComponentWithoutOwnerOrContext<strong i="19">@141</strong>:7295
                                                                _renderValidatedComponent<strong i="20">@141</strong>:7462
                                                                performInitialMount<strong i="21">@141</strong>:3012
                                                                mountComponent<strong i="22">@141</strong>:2056
                                                                mountComponent<strong i="23">@132</strong>:205
                                                                performInitialMount<strong i="24">@141</strong>:3162
                                                                mountComponent<strong i="25">@141</strong>:2056
                                                                mountComponent<strong i="26">@132</strong>:205
                                                                performInitialMount<strong i="27">@141</strong>:3162
                                                                mountComponent<strong i="28">@141</strong>:2056
                                                                mountComponent<strong i="29">@132</strong>:205

Olhando através do código, uma vez que getLocale vê que minha chave ('en-US') não é uma matriz, ela cai em loadLocale sem nunca tentar corresponder 'en', o que só aconteceria se fosse para a função chooseLocale.

EDITAR: depois de olhar um pouco mais de perto a função ChooseLocale, ela ainda tentaria primeiro escolher 'en-US' e, em seguida, falharia no require antes de tentar 'en', então o requerimento com falha levando a um aplicativo com falha ainda ocorreria se fosse uma matriz.
Também estranho é o fato de que o local onde ele está quebrando está dentro de um try / catch, mas causa um travamento de qualquer maneira. Essa é realmente a coisa realmente desconcertante aqui.

EDIT 2: Observe que o require falha normalmente quando em uma compilação de depuração (__DEV__) e então cai para o uso de 'en'. Não tenho certeza de por que require é muito mais explosiva em __PROD__, mas está definitivamente quebrando aqui.

EDIT 3: A partir dos documentos require js, "Se você não expressar as dependências, provavelmente obterá erros de carregamento, pois o RequireJS carrega scripts de forma assíncrona e fora de ordem para velocidade." Portanto, é improvável que o try / catch nos salve aqui, já que o try / catch só ajuda realmente com erros síncronos.

Então, depois de trabalhar um pouco, eu tenho uma solução alternativa (menos do que ideal). Basicamente, sempre que meu código tenta passar em uma localidade 'en-US', eu o intercepto e passo em uma localidade 'en'. Outras localidades podem passar inalteradas.

Dito isso, ainda acho problemático que ele não consiga encontrar en-US nem o padrão para já tê-lo, e você não pode incluí-lo especificamente como faria com outras localidades para evitar a falha em encontrá-lo quando é realmente chamado em cima.

@steveccable

Também estranho é o fato de que o local onde ele está quebrando está dentro de um try / catch, mas causa um travamento de qualquer maneira. Essa é realmente a coisa realmente desconcertante aqui.

Certo, é isso que estou dizendo. Estou tentando entender por que uma chamada de solicitação com falha seria catastrófica. Eu não ajudaria a codificar no conhecimento de en-US ; ainda teríamos uma falha semelhante em qualquer outro caso de fallback. ou seja, isso não tem nada a ver com en ser um caso especial, mas sim com o processo de fallback não funcionando em seu ambiente.

Trabalhando com isso, parece que o React Native não está lidando com as necessidades de falha tão graciosamente quanto gostaríamos. Você está correto ao dizer que não tem nada a ver com en ser um caso especial, e a única razão pela qual parecia que era especial era porque não havia como evitar que o requerimento en-US falhasse (já que não podemos importá-lo diretamente como com outras localidades). Conforme mencionado na edição posterior, o try / catch não funciona porque falha de forma assíncrona.
Por enquanto, a solução alternativa que mencionei acima de apenas limpar os locais de 'en-US' funciona para meus propósitos.

o try / catch não funciona porque falha de forma assíncrona

Oh, eu perdi aquela edição. Esse também seria o meu palpite.

@steveccable
Não tenho certeza se você ainda tem o problema, mas as mesmas falhas na versão de lançamento (embora com a localidade francesa) consumiram um dia de trabalho para mim 😢

E/ReactNativeJS: Requiring unknown module "./locale/fr".
(...)

Resolvi com:

import 'moment/locale/fr';

Talvez ajude

A solução alternativa para limpar a entrada de localidade está ok, mas é realmente assustador saber que um require () nativo de reação pode falhar de forma assíncrona em qualquer lugar e não há como detectar isso. Além disso, se eu enviar um local não existente ou uma string aleatória (diga 'blá-blá'), isso significa que o aplicativo trava e não consigo lidar com o erro em lugar nenhum. Então, eu tenho que estar defensivamente verificando se ninguém aciona esse bug.

Tive problemas após a versão 2.19.2 aqui está o que mudou com essa versão https://github.com/moment/moment/compare/29afed6...328d51e a função updateLocale começou a usar loadLocale internamente que, por sua vez, usa require com uma string dinâmica https : //github.com/moment/moment/blob/fea48bb69eda8c0459915d6aa66a910a4d43a55b/moment.js#L1845

Eu acho que isso falha na reação nativa, porque você não pode exigir arquivos dinamicamente pela variável https://github.com/facebook/react-native/issues/6391

No meu caso específico, estou importando o arquivo en-gb, então ele deve ser encontrado em locales[name] no momento em que chamo moment.locale. Não tenho certeza de por que isso é necessário.

não tenho certeza se RN é uma prioridade ou não, mas o momento para RN será interrompido por meses.

Com tudo isso, parece que o Facebook # 69 é a solução mais produtiva para desbloquear a todos. Vou falar com @jeanlauliac e veremos se podemos mesclá-lo na segunda-feira.

Só para dar algumas informações básicas: há vários motivos pelos quais não oferecemos suporte a dependências dinâmicas. Primeiro, a análise estática é interrompida ao exigir módulos dinamicamente. Em segundo lugar, ao usar requerimentos dinâmicos, o módulo real que você está procurando pode não estar disponível. Isso pode causar grandes problemas na produção que impediriam os usuários de usar nossos aplicativos, como por exemplo, podemos quebrar o Facebook. Tivemos problemas como este no passado e não é divertido lidar com eles. O Metro tem uma opinião intencional para evitar que as pessoas façam coisas que causem dor aos usuários.

Finalmente, entendemos que este repositório de código aberto não está em uma ótima forma no momento. A boa notícia é que nunca houve mais pessoas no FB trabalhando no Metro, e temos uma série de mudanças importantes na loja para tornar o Metro ainda melhor, mas a má notícia é que existem questões urgentes que precisamos resolver. para abrir o código. Esperamos que em alguns meses esse repo esteja em um estado muito melhor e que seja mais fácil contribuir para ele. Dê-nos algum tempo, por favor.

Para RN, fiz funcionar no modo de liberação, removendo para a primeira parte do local (provavelmente o momento que ocorre atrás das telas quando falha ao carregar o local "xx-XX"). No trecho a seguir, locale é a localidade do seu dispositivo no formato "xx-XX".

moment.locale(locale.indexOf("-") === -1 ? locale : locale.substr(0, locale.indexOf('-')))

Este é um comportamento estranho.

https://stackoverflow.com/a/47260841/175825 você precisa importar um local específico para que o ecossistema possa consumi-los.

Por causa dessa mágica, não consigo fazer o react-big-calendar exibir datas como mm/yy usando BigCalendar.momentLocalizer() porque ele está esperando qualquer localidade carregada.

Eu poderia abrir um problema com react-big-calendar, mas e a próxima lib que encontro esperando um local específico? E o próximo?

Basta adicionar en-us locale e usar como padrão mágico.

Basta adicionar a localidade en-us e usar como padrão mágico.

Isso não vai resolver o problema, há idiomas como o espanhol ( es-ES => es ) que fazem fallback automático.

Para quem ainda está procurando por uma solução, isso pode ajudar a mitigar o problema (com exceção de alguns casos extremos), mas não corrige o problema raiz de RN causando uma falha durante o try-catch require :

import moment from 'moment/min/moment-with-locales.min.js';

// locale is the locale detected by react-native-device-info
// ts is the time
export const formatTime = (locale, ts) => {
const m = moment.utc(ts);
locale = chooseMomentLocale(locale);
m.locale(locale);
// other logic to determine whether to show the time as "9:43 pm", "yesterday", or "7/8/2018"

return formattedTime;
}

/**
 * Checks if the device locale is available in moment and returns the locale to be loaded
 * <strong i="7">@param</strong>  {string} locale locale to be checked
 * <strong i="8">@return</strong> {string}        locale to be loaded by moment
 */
const chooseMomentLocale = (locale) => {
  // make the locale lower case 
  // will fix crashes caused by "en-GB" (instead of "en-gb") not being found
  locale = locale.toLowerCase();  
  if (moment.locales().includes(locale)) { // check if the locale is included in the array returned by `locales()` which (in this case) tells us which locales moment will support
    return locale;
  } else if (moment.locales().includes(locale.substring(0, 2))) { 
    // check if the first two letters of the locale are included in the array returned by `locales()` which (in this case) tells us which locales moment will support
    // will fixes crashes caused by "en-US" not being found, as we'll tell moment to load "en" instead
    return locale.substring(0, 2);
  }
    // use "en-gb" (the default language and locale for my app) as a fallback if we can't find any other locale
    return 'en-gb'; 
};

Também tive esse problema ao usar o React Native e consegui evitá-lo incluindo todos os locais ao lado do Moment, ou

import moment from 'moment'
import 'moment/min/locales'

(Alternativamente, moment/min/moment-with-locales também é fornecido, mas não era compatível com alguns de nossos outros formatadores.)

Este é um problema super irritante.

Não é o ponto principal das localidades que você nem mesmo tem que pensar sobre isso e certamente não estar codificando 'en-US' em seu código apenas porque VOCÊ está nos EUA? Não entendo por que, ao solicitar uma localidade de 'en-US', não posso simplesmente aceitá-la. Causa dores de cabeça sem fim.

Resolvi esse problema há um ano, mas esqueci completamente como, então tenho que começar tudo de novo. (Estou usando um selecionador de data no Angular e apenas colocando a implementação mínima em explode com esse erro).

Estou recebendo isso no Angular tentando usar o seletor de data e hora. Se eu definir LOCALE para algo como en-GB, ele funciona bem, mas sem especificar nada, eu obtenho isso. Eu gostaria de poder descobrir a maneira adequada de consertar isso

Para RN, fiz funcionar no modo de liberação, removendo para a primeira parte do local (provavelmente o momento que ocorre atrás das telas quando falha ao carregar o local "xx-XX"). No seguinte recorte, locale é a localidade do seu dispositivo no formato "xx-XX".

moment.locale(locale.indexOf("-") === -1 ? locale : locale.substr(0, locale.indexOf('-')))

Esta solução funciona para mim, usando i18n e momentjs assim:

// imports:
import moment from 'moment';
import i18n from './i18n';
import 'moment/locale/fr';

// constructor: 
moment.locale(i18n.locale.indexOf('-') === -1 ? i18n.locale : i18n.locale.substr(0, i18n.locale.indexOf('-')));

Ainda estou tendo esse problema ao executar a versão "moment": "^ 2.22.2",
Alguma correção na última versão?

Eu vou comentar sobre esse assunto.

1. tratar o en-US como um padrão oculto diferente dos outros é um projeto ruim.
2. sem localidade en-us, não sei qual versão do CDN usar.
3. O momento parece impressionante, mas não encontrarei outra solução, pois en-US não ser igual a outras localidades é um mau cheiro de código.

Eu também tive esse erro no reagente nativo na produção depois de fazer um bom desenvolvimento construído que funciona perfeitamente.
Resolvido com a solução proposta por @adesmet e o seguinte refatorador:

function parseLocaleForMoment (language) {
  if (language.indexOf('-') === -1) return language
  else return language.substr(0, language.indexOf('-'))
}

Parece que o RN suga tanto com o momento que é mais fácil apenas escrever um formatador nativo. Provavelmente apenas uma linha de código, à prova de balas para funcionar.

Acabou consertando assim:

const subLocales = [
  'ar-tn',
  'ar-dz',
  'ar-kw',
  'ar-ma',
  'ar-sa',
  'ar-ly',
  'de-at',
  'de-ch',
  'en-sg',
  'en-au',
  'en-ca',
  'en-gb',
  'en-ie',
  'en-nz',
  'es-us',
  'es-do',
  'fr-ca',
  'fr-ch',
  'gom-latn',
  'hy-am',
  'pa-in',
  'pt-br',
  'sr-cyrl',
  'tl-ph',
  'tlh',
  'tet',
  'ms-my',
  'it-ch',
  'tzl',
  'tzm',
  'tzm-latn',
  'nl-be',
  'ug-cn',
  'uz-latn',
  'zh-cn',
  'zh-hk',
  'zh-tw'
];

let momentLocale = i18n.locale.toLowerCase();

if (!subLocales.includes(momentLocale)) {
  momentLocale = momentLocale.substring(0, 2);
}

moment.locale(momentLocale);

com react native zh por alguns motivos: /

Isso pode ser porque zh e alguns outros locais são formatados de forma diferente para diferenciar entre simplificado e tradicional. Veja https://gist.github.com/jacobbubu/1836273

@ rajivshah3 na verdade eu estava tendo zh_Hant_HK que não estava funcionando com o método tapz. Agora estou usando o seu método, que parece ser a melhor maneira de lidar com este problema da maneira mais suave possível, obrigado pela sua postagem 👍

Mesmo problema, apenas no modo de produção RN.

Isso parece funcionar bem para mim.

import 'moment/locale/fr';
import 'moment/locale/es';
import 'moment/locale/de';
import 'moment/locale/en-gb';
import 'moment/locale/es-us';

const toMomentLocale = locale => {
  let momentLocale = locale;
  momentLocale = momentLocale.replace('_', '-').toLowerCase();
  momentLocale = ['en-gb', 'en-us'].includes(locale)
    ? momentLocale
    : momentLocale.split('-')[0];
  return momentLocale;
};

Contanto que os dados sejam importados (ou en ) e respeitem o caso, parece funcionar bem para nós

Isso é realmente ridículo. Eliminar a seção -region do código de idioma não é uma solução.

1) Você perde a especificidade regional do local.
2) Pior ainda, esse método causará mais travamentos. Chinês ( zh ), por exemplo, nem mesmo existe nas localidades do MomentJS. Apenas zh-cn , zh-hk e zh-tw são definidos. Portanto, se você estiver usando o código acima para remover regiões da string de localidade, seu aplicativo irá travar imediatamente na maioria dos dispositivos chineses. Apenas cerca de 800 milhões de usuários de smartphones.

Minha solução temporária (e totalmente absurda) para o React Native é esta:

const locale = 'zh-cn'; // or en-US etc
const languageCode = moment.locale(locale.indexOf("-") === -1 ? locale : locale.substr(0, locale.indexOf('-'))); // now 'zh', 'en' etc. Thanks <strong i="14">@adesmet</strong> 
let momentJsLocale;
switch(languageCode.toLowerCase()) {
  case 'zh':
    // No 'zh' locale exists in MomentJS. App will crash in production if used.
    momentJsLocale = 'zh-cn';
    break;
  case 'pa':
    momentJsLocale = 'pa-in';
    break;
  case 'hy':
    momentJsLocale = 'hy-am';
    break;
  default:
    momentJsLocale = languageCode.toLowerCase();
}
moment.locale(momentJsLocale);

@adammcarth Olá, temos alguma notícia sobre a correção de locales de momento para RN?

Isso apenas travou em uma versão de lançamento agora usando en-gb .

Eu recebo um problema semelhante ao; @simeyla .

Quando adicionei o Luxon junto com o seletor de tempo, problemas surgiram e parecem estar relacionados ao local 'en-US'.

@steveccable Bem, ele tenta carregá-lo, apenas no caso de você ter uma localização mais específica. Quando falha, ele tenta apenas "en" e é bem-sucedido. Acho que a desconexão é apenas que de alguma forma a falha ao carregar "en-US" está quebrando para você. Nada deve explodir aqui; _apenas deve falhar graciosamente_ e passar para a próxima opção. Portanto, você terá que me contar mais sobre seu ambiente: o que, especificamente, está errado?

Outro problema em lidar com 'en-US' ou outras localidades válidas com exceções é quando você está depurando e pede ao depurador para travar nas exceções, você fica preso neste aqui repetidamente.

Deve haver uma maneira melhor e mais simples, especialmente para um local tão grande como o 'en-US'.
Eventualmente, essas localidades com possibilidade de grande público / uso devem ser verificadas e tratadas na frente, para consideração de velocidade.

Modifiquei a solução de

const toMomentLocale = (locale) => {
  let newLocale = locale.replace('_', '-').toLowerCase();
  let tryLocales = [newLocale, newLocale.split('-')[0]];
  for (let i = 0; i < tryLocales.length; i++) {
    if (moment.locales().indexOf(tryLocales[i]) >= 0) return tryLocales[i];
  }
  return 'en-us';
};

// use it like this:
let m = moment();
m.locale(toMomentLocale('zh_CN')).format('LLL'); // "2019年12月11日上午9点33分" -- used "zh-cn"
moment.locale(toMomentLocale('ja_JP'));
moment().format('LLL') // 2019年12月11日 09:34 -- falls back to "ja"

Mesmo problema, apenas no modo IOS de produção RN.

Isso parece funcionar bem para mim.

importar momento de "momento";
importar 'momento / local / es';

Gastei algum tempo depurando isso, obrigado

Isso ainda é um problema 😢

Oi pessoal,

Eu criei um pequeno pacote para você -> https://github.com/tonix-tuft/moment-utl

npm install --save moment moment-utl

Você pode usar o seguinte para determinar todos os locais de momento com suporte, sem a necessidade de carregá-los com antecedência:

import { allSupportedLocales, allSupportedLocalesMap } from "moment-utl";

const locales = allSupportedLocales(); // As an array: ["af", "ar", "ar-dz", "ar-kw", "ar-ly", "ar-ma", "ar-sa", "ar-tn", "az", "be", "bg", ...,  "en", ..., "zh-tw"]

const localesMap = allSupportedLocalesMap(); // As an object: { "af": 1, "ar": 2, "ar-dz": 3, "ar-kw": 4, "ar-ly": 5, "ar-ma": 6, "ar-sa": 7, "ar-tn": 8, "az": 9, "be": 10, ..., "en": 27, "zh-tw": 128 };

moment-utl peer depende de moment , mas agrupa todos os moment locales
retirando-os do diretório moment/locale durante sua construção de um pacote de dependência moment dev.

No entanto, como moment é uma dependência de par, se você estiver usando ES6 e quiser ter certeza de que allSupportedLocales e allSupportedLocalesMap usam localidades atualizadas com moment versão que você instalou em seu projeto junto com moment-utl (por exemplo, se moment adicionar uma nova localidade algum dia, então isso deve ajudar você), então você também pode regenerar essas localidades usando o moment-utl-locales script fornecido por moment-utl .

Você pode usá-lo com o comando npx :

npm install -g npx    # Install npx if you don't have it yet
npx moment-utl-locales    # Run this command from your project's root folder

Ao usar este script, apenas certifique-se de executá-lo antes de empacotar seu código com Rollup ou Webpack (o que você usar), de modo que ele irá gerar uma matriz de locales e um objeto atualizados antes que seu bundler os encontre e os adicione a seu pacote final.

Eu espero que isso ajude!

Em resposta a @adammcarth , verifique minha resposta aqui: https://github.com/tonix-tuft/moment-utl/issues/1#issuecomment -616088826

Esse problema tem assombrado os caras da Odoo e a correção sugerida foi criar o arquivo en-us manualmente. Suspiro.

O que não entendo é por que moment tenta carregar o arquivo en-us se, como dito alguns comentários acima, o carregador deve saber que já possui o "en" e não importá-lo dinamicamente.

De qualquer forma, ainda é um pesadelo para os usuários do RN. A pior parte é que o problema ocorre apenas em compilações de produção.

Ter um padrão oculto é um pacote de surpresas ...

Esse problema tem assombrado os caras da Odoo e a correção sugerida foi criar o arquivo en-us manualmente. Suspiro.

O que não entendo é por que moment tenta carregar o arquivo en-us se, como dito alguns comentários acima, o carregador deve saber que já possui o "en" e não importá-lo dinamicamente.

De qualquer forma, ainda é um pesadelo para os usuários do RN. A pior parte é que o problema ocorre apenas em compilações de produção.

Ter um padrão oculto é um pacote de surpresas ...

Vou conseguir 👎 para isso, mas minha solução era trocar moment por dayjs . Como eles compartilham a mesma função / nomenclatura de API, foi tão simples quanto find all + replace all para mim.

Apenas compartilhando o que eu fiz por pessoas que podem querer considerar isso.