Форматування дат у n8n: вправа перед записом
Практикуйте форматування дат у n8n: явні формати вводу, гілка перевірки й звіряння моментів часу в UTC — до підготовки даних для запису.
Перевірено за наведеними джерелами .
Ваша вправа з форматування дат у n8n
У цій редакційній вправі вам пропонується створити робочий процес форматування дат у n8n, який зберігає початкові значення, розбирає їх за явно заданими форматами, спрямовує записи з невизначеною інтерпретацією на перевірку та готує схвалені часові позначки для майбутнього запису в бізнес-систему. Документація n8n рекомендує явно розбирати дати за допомогою Luxon, оскільки між вузлами вони передаються як рядки. Вправа спирається на документацію; її не виконували й не перевіряли.
Використовуйте власне середовище n8n, вирази JavaScript і синтетичні записи. Для кожного вхідного значення визначте формат, локаль, часовий пояс джерела та значення: момент часу чи календарна дата. Ця вправа обробляє лише моменти часу. Цільову систему й вимоги до її полів не визначено, тому зупиніться перед будь-яким реальним записом; перевірка збережених значень, семантика цільових полів лише з датою, планування на майбутній місцевий час та оновлення правил часових поясів у базі даних виходять за межі вправи.
Надана документація n8n не визначає редакцію чи версію. Перш ніж починати, перевірте підтримку виразів у своєму середовищі. На нашу думку, явно визначити вимоги до вхідних даних корисніше, ніж збирати фрагменти виразів форматування: це змушує відкрито ухвалити важливі рішення щодо інтерпретації.
Підготуйте вхідні дані з очікуваними маршрутами
Використайте запропоновані нижче редакційні тестові дані. Два записи для переходів у America/New_York навмисно залишено з невизначеною інтерпретацією; вони спираються на історичні приклади з посібника Luxon щодо часових поясів: пропущений і повторений місцевий час. Залиште обидва на маршруті перевірки. Посібник пояснює, що відсутній час під час весняного переведення годинника може зміщуватися вперед, а час під час осіннього переведення може повторюватися; сама лише коректність розбору не визначає задуманий місцевий час чи конкретне його повторення.
| Вхідне значення | Задана інтерпретація | Очікуваний маршрут |
|---|---|---|
| 2026-01-15T10:00:00+02:00 | Момент часу в ISO з явним зміщенням | Схвалено |
| 2026-01-15T10:00:00 | Місцевий час в ISO; часовий пояс джерела — UTC | Перевірка |
| 03/04/2026 09:00 | Порядок компонентів дати зі скісними рисками не задано | Перевірка |
| 2026-02-30T10:00:00Z | Момент часу в ISO; неможлива календарна дата | Перевірка |
| 2017-03-12T02:30:00 | America/New_York; інтерпретацію пропущеного часу не визначено | Перевірка |
| 2017-11-05T01:30:00 | America/New_York; конкретне повторення часу не визначено | Перевірка |
Sources: luxon/docs/parsing.md at master · moment/luxon · GitHub, luxon/docs/zones.md at master · moment/luxon · GitHub
n8n: розберіть дату й збережіть вихідні дані
Практикуючи розбір дати в n8n, зберігайте початкове значення поруч із його інтерпретацією. Edit Fields може створювати або перезаписувати поля. Використайте його, щоб зберегти rawDate, declaredFormat, locale, sourceZone і meaning; ці назви полів обрано для вправи. Потім виконайте запропоновану послідовність.
- Збережіть незмінене вхідне значення та явно задані вимоги до нього.
- Розбирайте рядки ISO за допомогою DateTime.fromISO(rawDate, { zone: sourceZone }).
- Розбирайте рядки із заданим власним форматом за допомогою DateTime.fromFormat(rawDate, declaredFormat, { zone: sourceZone, locale: locale }).
- Зафіксуйте isValid та invalidReason перед спробою серіалізації.
- Якщо розбір не вдався, дослідіть результат DateTime.fromFormatExplain з тим самим значенням, форматом і параметрами.
У документації Luxon 3.7.2 параметр zone методу fromISO задає інтерпретацію, коли вхідне значення не містить зміщення; це джерело не визначає версію Luxon, що входить до вашого екземпляра n8n. Не робіть висновку про автоматичне виявлення неоднозначності на основі наданих матеріалів: посібник із часових поясів і версійний довідник API висвітлюють це по-різному.
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
Спрямуйте невизначені записи на перевірку перед форматуванням
Створіть запропонований прапорець схвалення, який вимагає і коректного розбору, і визначеної інтерпретації. Використайте задокументоване розгалуження за порівнянням у вузлі If, щоб відокремити схвалені записи від записів для перевірки. Значення без часового поясу джерела, дати зі скісними рисками без заданого порядку компонентів і тестові записи переходів із невизначеною інтерпретацією мають потрапляти до гілки перевірки. Не підключайте цю гілку до шляху майбутнього запису та зберігайте конкретну причину перевірки.
Для схвалених записів попрактикуйте форматування дат у n8n. Надане підтримуване спільнотою дзеркало документації описує From Date Format для нерозпізнаних вхідних значень і Use Workflow Timezone для вибору між часовим поясом вхідного значення та часового поясу робочого процесу. Перевірте ці елементи керування у встановленому вузлі й зробіть вибір явно; дзеркало не датоване, неповне та не визначає версії чи редакції.
Запропонована конфігурація вправи з використанням елементів керування, описаних у цьому дзеркалі спільноти: після схвалення збережіть approvedISO = parsed.toISO() і sourceMillis = parsed.toMillis(). Виберіть Format a Date, задайте для Date поле approvedISO, виберіть Custom Format зі значенням yyyy-MM-dd і встановіть Output Field Name у displayDate. Вимкніть Use Workflow Timezone та ввімкніть Include Input Fields; залиште From Date Format незаданим для цього значення ISO. Використовуйте displayDate лише як поле для відображення, окремо від часової позначки в даних для запису. На наступному кроці ви створите й перевірите поле UTC для запису.
На нашу думку, явний запис для перевірки — кращий результат вправи, ніж правдоподібна часова позначка, отримана здогадками.
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
Перевірте вихідне значення UTC і рівність моментів часу
Завершіть шлях форматування дат у n8n після вузла форматування. Перевірте коректність DateTime.fromISO($json.approvedISO), а потім створіть payloadTimestamp за допомогою DateTime.fromISO($json.approvedISO).toUTC().toISO(), використовуючи стандартну поведінку перетворення. Тримайте displayDate окремо: payloadTimestamp — це часова позначка в запропонованих даних для запису. Довідник виразів n8n зазначає, що toUTC за замовчуванням зберігає момент часу, а toISO створює рядок ISO.
Повторно розберіть фактичне поле payloadTimestamp за допомогою DateTime.fromISO($json.payloadTimestamp) і вимагайте isValid перед порівнянням його значення toMillis() зі збереженим sourceMillis із початкового схваленого розбору. Ця запропонована перевірка проходить лише за рівності значень. Порівнюйте моменти часу, а не текст для відображення, і спрямовуйте некоректну часову позначку для запису або невідповідність на перевірку.
Запропонований розібраний приклад: для 2026-01-15T10:00:00+02:00 очікуване значення payloadTimestamp — 2026-01-15T08:00:00.000Z. Повторно розберіть це поле за допомогою DateTime.fromISO і вимагайте, щоб його значення toMillis дорівнювало sourceMillis. Контрольний список завершення:
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
Проаналізуйте запропоноване рішення
Ваше запропоноване рішення має давати змогу перевірити інтерпретацію: початкове значення, явно заданий метод розбору, рішення про схвалення, відформатоване значення та порівняння моментів часу. Коли тестовий запис весняного переведення годинника змінюється неочікувано, порівняйте початкові компоненти місцевого часу з розібраними; коректний результат усе одно може відображати нормалізацію. Використовуйте fromFormatExplain, досліджуючи відповідність токенам формату.
Запропоновані запитання для роздумів: які припущення випливали з вимог до даних джерела? Які записи потребували уточнення людиною? Які вимоги до цільового поля ви визначили б перед підключенням запропонованих даних до операції запису?
Sources: luxon/docs/zones.md at master · moment/luxon · GitHub, luxon/docs/parsing.md at master · moment/luxon · GitHub
