Moment: Procure o indicador meridiem ao combinar o formato iso

Criado em 23 fev. 2016  ·  15Comentários  ·  Fonte: moment/moment

Conforme apresentado em # 2983, usar o formato de data "2016-02-23 11:31:23 PM" corresponderá a um formato ISO, embora não seja. Isso faz com que uma data errada seja analisada:

moment('2016-02-23 11:31:23 PM').format() = "2016-02-23T11:31:23-06:00"

Isso ocorre porque 2016-02-23 11:31:23 é tecnicamente um formato ISO.
Precisamos alterar o arquivo from-string para verificar se há um indicador de meridiem e fazer algo diferente do formato ISO, se houver.

Bug Forgiving parsing

Todos 15 comentários

Ai! Aquele parece que pode morder alguém com certeza. Nenhum aviso de descontinuação também.

Parece que talvez seja suficiente certificar-se de que o verificador ISO vai até o final da string, por exemplo, adicionando $ ao final de extendedIsoRegex e basicIsoRegex .

@icambron Acho que não podemos fazer isso. Atualmente, o seguinte teste passa:

    assert.ok(moment('2016-01-01 is my date').isValid(), 'test extra chars after iso date')

É quase certo que existe alguém no mundo fazendo isso. Altere a regex e esse teste falhará (junto com alguns outros que ainda não pesquisei).

Hmm, ok. Minha opinião seria descontinuar isso e corrigir esse problema de AM / PM quando encerrarmos o suporte para ele. Não vejo um bom motivo pelo qual _devemos_ apoiar moment('2016-01-01 is my date')

Estive pensando um pouco sobre isso e me pergunto se a resposta menos invasiva para alguns dos problemas do analisador que estamos vendo - como este - seria realmente padronizar o analisador para o modo estrito. Parece que, na maioria das vezes, os problemas de perdão de análise (como este) são resolvidos ao alternar para o modo estrito (porque o usuário deveria estar usando o modo estrito em primeiro lugar). Talvez esta seja uma daquelas coisas para 'ajudar as pessoas a cair no poço do sucesso'? Isso deixaria a funcionalidade existente possível, mas direcione o desenvolvedor para o caminho certo.

Concordo, há muito tempo queremos fazer isso. Acho que está listado como um possível item 3.0 há muito tempo. Mas certamente ter a assinatura automagic one-arg estrita é um pequeno passo nessa direção.

Na verdade, comecei a codificar o modo estrito por padrão hoje, adicionando uma variável de estado global alternável chamada globalStrict, que assumi como verdadeira por padrão. A configuração do modo estrito pode então ser alternada de volta para falsa chamando:

moment.globalStrict(false)

Isso faz com que tudo se comporte da maneira que sempre fez, sem ter que mudar cada chamada para o analisador de momento.
Demora cerca de quatro linhas de código para fazer essa alteração - e depois é preciso corrigir centenas de testes de unidade :-)
Para mim, porém, esta pode ser uma maneira de lançar estritamente por padrão, sem ter que esperar pela v3.
Eu sinto que, uma vez que os usuários podem facilmente mudar de volta, eles podem aceitar a mudança sem muita reclamação.

Como alternativa, a configuração globalStrict pode ser definida como falsa por padrão e podemos encorajar fortemente os desenvolvedores a defini-la como verdadeira na documentação. Isso é menos invasivo e talvez útil?
Serei a primeira pessoa a dizer que as variáveis ​​de estado globais SUGAM do ponto de vista de testabilidade, e só por essa razão essa ideia pode ser terrível.

Eu também poderia, como sugerido, apenas usar como padrão as chamadas de um argumento para o modo estrito. Isso vai incomodar provavelmente milhares de pessoas que ainda estão voltando para a construção de datas JS.

Gosto de tudo isso, exceto uma coisa:

Isso vai incomodar provavelmente milhares de pessoas que ainda estão voltando para a construção de datas JS.

Para ser claro, minha sugestão não era acabar com a depreciação do construtor não pode voltar para JS. Na verdade, o oposto: neste caso, queremos fazer exatamente isso, mas a verificação ISO está nos antecipando.

Então, você está dizendo que tentaria a coisa do estado global, ou que iria evitá-la? Talvez eu apenas termine os testes de unidade e faça o PR e possamos conversar sobre isso lá.

Desculpe, não fui claro: não sou contra a coisa do estado global de forma alguma. Só não acho que isso nos impeça de fazer a verificação ISO de moment(string) estrita o tempo todo, mesmo sem o estado definido.

@maggiepint, obrigado por me indicar o tópico certo.
e você afirmou corretamente acima que eu era "uma daquelas pessoas lá fora": P fazendo coisas como
moment("2016-04-06Tnull").isValid()
com total confiança, aquele momento rejeitará uma string inválida.

Então, qual é a maneira mais fácil de ativar a análise estrita por padrão? (desculpe, sendo preguiçoso)

@Aukhan , nunca implementamos global strict por causa de um problema com a análise de modo estrito que precisava ser corrigido primeiro. (mas era, então ainda podemos chegar lá).

Para realizar o que você está fazendo, acho que você só precisa especificar a constante ISO_8601 e o modo estrito embutido em seu código:

moment("2016-04-06Tnull", moment.ISO_8601, true).isValid()
false

@maggiepint obrigado novamente pela sua resposta ...

Essa é uma ótima sugestão, mas eu não gostaria de substituir centenas dessas expressões onde não apenas o ISO_8601, mas também formatos personalizados diferentes estão sendo usados, então acho que seria bom ter a opção estrita global.
Comecei a pesquisar a base de código, mas obviamente um trabalho tão grande e excelente não pode ser compreendido da noite para o dia.

Posso não ter as habilidades necessárias, mas se puder ajudar de alguma forma, por favor, me avise.
Obrigado !

@Aukhan , vou ver se não consigo pegar aquele item de trabalho novamente. O problema é que, para fazê-lo funcionar, o PR # 3078 precisa ser mesclado. Foi por isso que a coisa caiu em primeiro lugar.

Fechando em favor de # 3502

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

chitgoks picture chitgoks  ·  3Comentários

danieljsinclair picture danieljsinclair  ·  3Comentários

dogukankotan picture dogukankotan  ·  3Comentários

paulyoung picture paulyoung  ·  3Comentários

RobinvanderVliet picture RobinvanderVliet  ·  3Comentários