Formato de fechas en n8n: un ejercicio previo a la escritura
Practica el formato de fechas en n8n con formatos declarados, una rama de revisión y comprobaciones de instantes UTC, sin ejecutar la escritura.
Comprobado con las fuentes citadas el .
Tu ejercicio de formato de fechas en n8n
Este ejercicio editorial te propone crear un flujo de formato de fechas en n8n que conserve las entradas originales, interprete formatos declarados, dirija los registros sin resolver a revisión y prepare marcas de tiempo aprobadas para una propuesta de escritura en un sistema empresarial. La documentación de n8n recomienda el análisis explícito con Luxon porque las fechas pasan entre nodos como cadenas de texto. El ejercicio se basa en documentación; no se ha ejecutado ni validado.
Utiliza tu propio entorno de n8n, expresiones JavaScript y registros sintéticos. Define el formato, la configuración regional, la zona horaria de origen y el significado de cada entrada: instante o fecha de calendario. Este ejercicio procesa únicamente instantes. No se especifica ningún sistema de destino ni contrato de campo, así que detente antes de realizar cualquier escritura real; quedan fuera del alcance la verificación de valores almacenados, la semántica de fechas sin hora en el destino, la programación futura en hora local y las actualizaciones de las reglas de zonas horarias de la base de datos.
La documentación de n8n proporcionada no establece ninguna edición ni versión. Comprueba la compatibilidad con las expresiones en tu entorno antes de continuar. Creemos que hacer explícito el contrato de entrada resulta más útil que recopilar fragmentos de formato: obliga a exponer las decisiones importantes de interpretación.
Prepara entradas con destinos esperados
Utiliza los siguientes datos de prueba sugeridos para este ejercicio editorial. Los dos registros de transición de America/New_York son entradas deliberadamente sin resolver que utilizan los casos históricos de la guía de zonas horarias de Luxon: una hora local omitida y una hora local repetida. Mantén ambos en la ruta de revisión. La guía explica que las horas inexistentes del cambio al horario de verano pueden adelantarse y que las del cambio al horario de invierno pueden repetirse; la validez del análisis por sí sola no determina la hora local ni la ocurrencia que se pretendía representar.
| Entrada | Interpretación declarada | Ruta esperada |
|---|---|---|
| 2026-01-15T10:00:00+02:00 | Instante ISO con desplazamiento explícito | Aprobación |
| 2026-01-15T10:00:00 | Hora local ISO; zona horaria de origen UTC | Aprobación |
| 03/04/2026 09:00 | Sin convención declarada para fechas con barras | Revisión |
| 2026-02-30T10:00:00Z | Instante ISO; fecha de calendario imposible | Revisión |
| 2017-03-12T02:30:00 | America/New_York; hora omitida sin resolver | Revisión |
| 2017-11-05T01:30:00 | America/New_York; ocurrencia repetida sin resolver | Revisión |
Sources: luxon/docs/parsing.md at master · moment/luxon · GitHub, luxon/docs/zones.md at master · moment/luxon · GitHub
n8n: analiza una fecha y conserva las evidencias
Al practicar cómo analizar una fecha en n8n, conserva el valor original junto a su interpretación. Edit Fields puede crear o sobrescribir campos. Úsalo para conservar rawDate, declaredFormat, locale, sourceZone y meaning; estos nombres de campo son decisiones editoriales. Después, aplica esta secuencia sugerida.
- Conserva la entrada intacta y su contrato declarado.
- Analiza las cadenas ISO con DateTime.fromISO(rawDate, { zone: sourceZone }).
- Analiza las cadenas personalizadas con un contrato definido mediante DateTime.fromFormat(rawDate, declaredFormat, { zone: sourceZone, locale: locale }).
- Registra isValid e invalidReason antes de intentar la serialización.
- Si falla el análisis, inspecciona DateTime.fromFormatExplain con la misma entrada, formato y opciones.
Luxon 3.7.2 documenta que la opción zone de fromISO proporciona la interpretación cuando una entrada no tiene desplazamiento; esa referencia no establece qué versión de Luxon incluye tu instancia de n8n. No deduzcas que existe detección automática de ambigüedades a partir del material proporcionado: la guía de zonas horarias y el índice de la API con versión lo tratan de forma diferente.
Sources: n8n-docs/docs/build/work-with-data/handle-special-data-types/work-with-dates-and-times.md at main · n8n-io/n8n-docs · GitHub, luxon/docs/parsing.md at master · moment/luxon · GitHub, luxon 3.7.2 | Documentation, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.set.md at main · n8n-io/n8n-docs · GitHub
Dirige los registros sin resolver antes de aplicar el formato
Crea un indicador de aprobación sugerido que exija tanto un análisis válido como una interpretación resuelta. Utiliza la bifurcación por comparaciones documentada del nodo If para separar los registros aprobados de los que necesitan revisión. Las zonas horarias de origen ausentes, las convenciones no declaradas de fechas con barras y los datos de prueba de transiciones sin resolver deben ir a la rama de revisión. Mantén esa rama desconectada de la ruta propuesta de escritura y conserva un motivo específico de revisión.
Para los registros aprobados, practica el formato de fechas en n8n. La copia comunitaria proporcionada de la documentación describe From Date Format para entradas no reconocidas y Use Workflow Timezone para elegir entre la zona horaria de la entrada y la del flujo. Consulta esos controles en el nodo que tengas instalado y elige de forma explícita; la copia no tiene fecha, está truncada y no establece ninguna versión ni edición.
Configuración sugerida para el ejercicio, utilizando los controles descritos en esa copia comunitaria: conserva approvedISO = parsed.toISO() y sourceMillis = parsed.toMillis() después de la aprobación. Selecciona Format a Date, establece Date en el campo approvedISO, elige Custom Format con yyyy-MM-dd y establece Output Field Name en displayDate. Desactiva Use Workflow Timezone y activa Include Input Fields; deja From Date Format sin configurar para esta entrada ISO. Trata displayDate únicamente como un campo de visualización, separado de la marca de tiempo de los datos que se enviarían. El siguiente paso crea y comprueba el campo UTC de esos datos.
En nuestra opinión, un registro de revisión visible es un mejor resultado para el ejercicio que una marca de tiempo plausible producida mediante suposiciones.
Sources: n8n-docs/docs/build/work-with-data/handle-special-data-types/work-with-dates-and-times.md at main · n8n-io/n8n-docs · GitHub, luxon/docs/parsing.md at master · moment/luxon · GitHub, luxon/docs/zones.md at master · moment/luxon · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.if.md at main · n8n-io/n8n-docs · GitHub, Date & Time | n8n Docs, n8n-docs/docs/build/work-with-data/transform-data/expression-reference/datetime.md at main · n8n-io/n8n-docs · GitHub
Comprueba la salida UTC y la igualdad de instantes
Completa la ruta de formato de fechas en n8n después del nodo de formato. Valida DateTime.fromISO($json.approvedISO) y, después, crea payloadTimestamp con DateTime.fromISO($json.approvedISO).toUTC().toISO(), utilizando el comportamiento de conversión predeterminado. Mantén displayDate separado: payloadTimestamp es la marca de tiempo de los datos propuestos para el envío. La referencia de expresiones de n8n documenta que toUTC conserva el instante de forma predeterminada y que toISO produce una cadena ISO.
Vuelve a analizar el campo payloadTimestamp real con DateTime.fromISO($json.payloadTimestamp) y exige isValid antes de comparar su valor toMillis() con el sourceMillis conservado del análisis original aprobado. Solo una comparación que indique igualdad supera esta comprobación sugerida. Compara instantes en lugar del texto de visualización y dirige a revisión cualquier marca de tiempo de envío no válida o cualquier discrepancia.
Ejemplo resuelto sugerido: para 2026-01-15T10:00:00+02:00, el payloadTimestamp esperado es 2026-01-15T08:00:00.000Z. Vuelve a analizar ese campo de envío con DateTime.fromISO y exige que su valor toMillis sea igual a sourceMillis. La lista de comprobación para completar el ejercicio es:
Sources: n8n-docs/docs/build/work-with-data/handle-special-data-types/work-with-dates-and-times.md at main · n8n-io/n8n-docs · GitHub, luxon/docs/parsing.md at master · moment/luxon · GitHub, n8n-docs/docs/build/work-with-data/transform-data/expression-reference/datetime.md at main · n8n-io/n8n-docs · GitHub
Reflexiona sobre la solución propuesta
Tu solución sugerida debería permitir inspeccionar la interpretación: entrada original, analizador explícito, decisión de aprobación, salida con formato y comparación de instantes. Cuando un dato de prueba del cambio al horario de verano cambie de forma inesperada, compara sus componentes originales de hora local con los componentes analizados; un resultado válido puede seguir reflejando una normalización. Utiliza fromFormatExplain al investigar la coincidencia de los tokens de formato.
Preguntas de reflexión sugeridas: ¿Qué supuestos procedían del contrato de origen? ¿Qué registros necesitaron aclaración humana? ¿Qué contrato de campo de destino exigirías antes de conectar los datos propuestos para el envío a una operación de escritura?
Sources: luxon/docs/zones.md at master · moment/luxon · GitHub, luxon/docs/parsing.md at master · moment/luxon · GitHub
