Moment: Busque el indicador meridiem cuando coincida con el formato iso

¡Ay! Ese parece que podría morder a alguien con seguridad. Sin advertencia de desaprobación tampoco.

Parece que es suficiente asegurarse de que el verificador ISO llegue hasta el final de la cadena, por ejemplo, agregando $ al final de extendedIsoRegex y basicIsoRegex .

@icambron No creo que podamos hacer eso. Actualmente pasa la siguiente prueba:

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

Es casi seguro que haya alguien en el mundo haciendo eso. Cambie la expresión regular y esa prueba fallará (junto con un par de otras que aún no he buscado).

Mmm, ok. Mi opinión sería desaprobar eso y arreglar esto AM / PM cuando dejemos de admitirlo. No veo una buena razón por la que _deberíamos_ apoyar moment('2016-01-01 is my date')

He estado pensando un poco en esto, y me pregunto si la respuesta menos invasiva a algunos de los problemas del analizador que estamos viendo, como este, sería en realidad predeterminar el analizador en modo estricto. Parece que la mayoría de las veces, los problemas de análisis sintáctico (como este) se resuelven cambiando al modo estricto (porque el usuario debería haber estado usando el modo estricto en primer lugar). ¿Quizás esta es una de esas cosas de 'ayudar a la gente a caer en el pozo del éxito'? Eso dejaría posible la funcionalidad existente, pero empujaría al desarrollador por el camino correcto.

De acuerdo, siempre hemos querido hacer eso. Creo que ha sido catalogado como un posible elemento 3.0 durante mucho tiempo. Pero, ciertamente, hacer que la firma automática de un argumento sea estricta es un pequeño paso hacia eso.

De hecho, comencé a codificar el modo estricto de forma predeterminada hoy agregando una variable de estado global que se puede alternar llamada globalStrict, que de forma predeterminada es verdadera. La configuración del modo estricto se puede volver a cambiar a falso llamando a:

moment.globalStrict(false)

Esto hace que todo se comporte como siempre, sin tener que cambiar cada llamada al analizador del momento.
Se necesitan aproximadamente cuatro líneas de código para realizar este cambio, y luego hay que corregir cientos de pruebas unitarias :-)
Para mí, sin embargo, esta podría ser una forma de implementar estrictamente por defecto sin tener que esperar a que v3.
Siento que dado que los usuarios pueden volver a cambiarlo fácilmente, podrían aceptar el cambio sin demasiadas quejas.

Alternativamente, la configuración globalStrict podría ser falsa por defecto, y podríamos animar a los desarrolladores a que la establezcan como verdadera en la documentación. ¿Esto es menos invasivo y quizás útil?
Seré la primera persona en decir que las variables de estado global son una mierda desde el punto de vista de la capacidad de prueba, y solo por esa razón, esta idea podría ser terrible.

También podría, como se sugirió, simplemente las llamadas de un argumento predeterminadas al modo estricto. Sin embargo, eso molestará a las probablemente miles de personas que todavía están recurriendo a la construcción de fecha JS.

Me gusta todo eso, excepto una cosa:

Sin embargo, eso molestará a las probablemente miles de personas que todavía están recurriendo a la construcción de fecha JS.

Para ser claros, mi sugerencia no fue terminar con la desaprobación del constructor de JS que no se puede volver atrás. De hecho, lo contrario: en este caso, queremos hacer precisamente eso, pero la verificación ISO nos está adelantando.

Entonces, ¿estás diciendo que probarías lo del estado global o que lo evitarías? Tal vez termine las pruebas unitarias y haga las relaciones públicas y podamos hablar de ello allí.

Lo siento, no estaba claro: no estoy en contra de la cuestión del estado global en absoluto. Simplemente no creo que nos impida hacer que el control ISO de moment(string) estricto todo el tiempo, incluso sin el estado establecido.

@maggiepint gracias por señalarme el hilo correcto.
y ha dicho correctamente anteriormente que yo era "una de esas personas": P haciendo cosas como
moment("2016-04-06Tnull").isValid()
con plena confianza en ese momento va a rechazar una cadena no válida.

Entonces, ¿cuál es la forma más fácil de activar el análisis estricto de forma predeterminada? (lo siento, siendo vago)

@Aukhan nunca implementamos el estricto global debido a un problema con el análisis del modo estricto que debía solucionarse primero. (pero lo fue, por lo que aún podemos llegar allí).

Para lograr lo que está haciendo, creo que solo necesita especificar el modo constante y estricto ISO_8601 en línea en su código:

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

@maggiepint gracias de nuevo por tu respuesta ...

Esa es una gran sugerencia, pero no quisiera reemplazar cientos de expresiones de este tipo en las que no solo se utilizan ISO_8601, sino también diferentes formatos personalizados, por lo que supongo que sería bueno tener la opción estricta global.
Comencé a investigar el código base, pero obviamente un trabajo tan grande y grandioso no se puede entender de la noche a la mañana.

Es posible que no tenga las habilidades requeridas, pero si puedo ayudar de alguna manera, hágamelo saber.
Gracias !

@Aukhan Veré si no puedo volver a recoger ese elemento de trabajo. El problema es que para que funcione, es necesario fusionar el PR # 3078. Por eso la cosa cayó en primer lugar.

Cierre a favor del # 3502