ISO 8601 vs RFC 3339: los dos formatos de fecha detrás de sus respuestas API

El campo 'ISO 8601' que rechaza el ISO 8601 válido: una fecha de la semana o un valor de precisión reducida enviado a una API que esperaba el RFC 3339

Un campo API descrito casualmente como “ISO 8601” puede aceptar solo una forma de fecha y hora. Enviar otra representación válida según los estándares aún puede fallar en su analizador. El remedio no es argumentar a partir del nombre general; se trata de documentar la gramática exacta del cable con ejemplos y pruebas de validación.

ToolAcre aporta una salida canónica estable de `Date.toISOString()`, pero no es un conjunto de conformidad para todas las representaciones. Trate la cadena generada como una forma de intercambio útil y compárela con el contrato API que realmente posee.

Por lo tanto, un esquema debe publicar una expresión regular o un tipo formal solo si refleja con precisión el analizador. Los ejemplos por sí solos son útiles, pero los casos de rechazo explícito cierran la ambigüedad.

Un estándar de fecha amplio y una gramática API estrecha no son intercambiables

El formulario generado contiene la fecha del calendario, `T`, tiempo en milisegundos y Z final. La implementación lo llama ISO 8601 (UTC) en la interfaz de usuario. La entrada acepta lo que lee JavaScript Date, incluido un desplazamiento explícito y la forma de fecha y hora sin zona del selector local.

Ese comportamiento es mucho más limitado que el de un analizador estándar completo. Las fechas semanales, los intervalos, las duraciones y la precisión reducida no tienen pruebas de repositorio. Una cadena aceptada por un navegador Fecha no está garantizada en todos los idiomas, y un formulario especializado rechazado no refuta su validez en otros lugares.

La precisión fija de milisegundos de la salida es una elección de formato, no una prueba de que la fuente midió milisegundos. Es posible que la fecha haya recibido un valor de segundo completo y aún imprima `.000`.

ToolAcre emite una forma con forma ISO; no valida el estándar ISO 8601 completo

El libro caracterizó el RFC 3339, su año y reglas de compensación obligatorias. No existe ningún texto RFC ni analizador dedicado en el conjunto fuente, por lo que esos detalles no se afirman. El contrato de autoría requiere omitir la precisión sin respaldo en lugar de citar un título de memoria.

Si su API significa RFC 3339, asígnele un nombre en el esquema y pruébelo con una implementación basada en la especificación real. ToolAcre puede conectar una época conocida con su salida UTC ISO para comparar, pero no puede certificar que una entrada arbitraria satisfaga ese perfil.

Esta es una salvaguardia editorial y de ingeniería: los perfiles de estándares son contratos precisos y, parafrasearlos sin el texto, se corre el riesgo de cambiar los requisitos de la documentación.

RFC 3339 los requisitos necesitan una fuente de estándares externos que no está presente en este repositorio

Las afirmaciones sobre separadores alternativos, designadores en minúsculas y `−00:00` dependen del lenguaje estándar exacto. Se omiten aquí. El propio detector de zona del convertidor reconoce la Z final o el `±HH:MM` numérico y marca las fechas y horas sin zona como locales; ese es el límite que podemos verificar.

Cree una validación de API a partir de ejemplos explícitos aceptados y casos de rechazo. No infiera permiso del conveniente analizador de JavaScript Date. Un navegador permisivo puede normalizar la entrada que un servidor estricto rechaza correctamente, ocultando defectos de interoperabilidad durante las pruebas manuales.

Un analizador dedicado que tenga en cuenta los estándares debería devolver motivos de error estructurados. Permitir que Date normalice la entrada amplia puede convertir un error de validación de API en una discrepancia multiplataforma posterior.

El separador específico y las reglas de compensación desconocida se omiten sin el texto de los estándares.

Los valores de época hacen que la aritmética y el ordenamiento sean compactos cuando la unidad y el origen son fijos. Las fechas y horas textuales hacen que una lectura UTC o de compensación sea visible para las personas y preservan ese designador en tránsito. Muchas API eligen una cadena canónica para evitar la ambigüedad de unidades o enteros de JavaScript.

Si una API incluye ambos, defina qué campo es autorizado y pruebe el acuerdo. Una cadena con formato obsoleto junto a una época nueva es peor que cualquiera de las dos por separado. ToolAcre puede comparar el par convirtiendo el número entero y verificando el valor ISO generado, pero la aplicación de la coherencia pertenece al productor.

Ejemplo resuelto: un instante, cuatro representaciones: segundos de época, milisegundos de época, una cadena RFC 3339 en UTC y una con un desplazamiento local

Utilice `2025-02-03T10:22:00.000Z` instantáneo. Sus formas de época son 1,738,578,120 segundos y 1,738,578,120,000 milisegundos. Una lectura de compensación explícita es `2025-02-03T12:22:00+02:00`; analizarlo en ToolAcre devuelve la misma fila ISO UTC canónica y de época.

Estas son cuatro representaciones verificables por el repositorio: segundos, milisegundos, salida toISOString y una cadena de desplazamiento numérico analizada por fecha. El ejemplo no afirma que todos los analizadores externos acepten la misma precisión fraccionaria o sintaxis de desplazamiento. Ejecute la propia validación de la API antes del envío.

Restar el desplazamiento +02:00 del reloj escrito produce 10:22 UTC. Esa simple igualdad es suficiente para probar esta entrada particular sin generalizar una gramática estándar completa.

Ejemplo resuelto: un instante en las cuatro formas que este repositorio puede verificar

Los encabezados HTTP y las fechas de los correos electrónicos utilizan contratos textuales que no se implementan aquí. ToolAcre no formatea esos protocolos ni promete que su salida ISO pueda ser sustituida. El instante de una marca de tiempo puede ser el mismo, aunque su representación de cable requerida sea diferente.

Mantenga la serialización del protocolo en adaptadores dedicados con dispositivos copiados de especificaciones autorizadas. Utilice la conversión de época para verificar el instante subyacente y luego pruebe la gramática por separado. Esto evita que un valor correcto en el calendario pase la revisión en un sobre sintácticamente no válido.

El adaptador dedicado también debe preservar si el desplazamiento faltante o desconocido tiene significado de dominio. Reducir cada fecha textual a una suposición local puede destruir esa información.

Otros protocolos textuales permanecen fuera del convertidor

Especifique el formato estrecho que acepta su API en lugar de depender de una etiqueta amplia. Para esta herramienta, la salida reproducible más segura es la cadena ISO UTC devuelta por `toISOString()`, y la entrada numérica más segura incluye un contrato explícito de segundos o milisegundos.

ToolAcre une esos formularios e informa suposiciones. No adjudica todos los casos extremos ISO 8601 o RFC 3339. La propiedad clara de la gramática, la unidad y el designador de zona es lo que hace que las marcas de tiempo sean portátiles, sin adjuntar un nombre estándar familiar a un campo poco especificado.

Un contrato preciso permite a los clientes fracasar temprano con mensajes útiles. Una etiqueta amplia lleva el desacuerdo al tiempo de ejecución, donde dos analizadores que de otro modo serían correctos pueden elegir subconjuntos diferentes.