n8n Schedule Trigger தவறான நேரத்தில் இயங்குவது ஏன்?

n8n schedule trigger ஏன் தவறான நேரத்தில் இயங்குகிறது

n8n-ன் schedule trigger தவறான நேரத்தில் இயங்குவதற்கு காரணம், n8n தனது timezone-ஐ மூன்று வெவ்வேறு இடங்களிலிருந்து வாசிப்பதே ஆகும். இதில் ஒன்றை மட்டும் சரிசெய்வது சிக்கலின் ஒரு பகுதியை மட்டுமே தீர்க்கும். அந்த மூன்று இடங்கள்: container-ன் சொந்த TZ variable, instance-ன் default GENERIC_TIMEZONE, மற்றும் ஒரு குறிப்பிட்ட workflow-க்குள் அமைக்கப்படும் timezone. இவை மூன்றையும் ஒரே நேரத்தில் சரியாக அமைத்தால், நீங்கள் உருவாக்கும் அனைத்து schedule-களும் நீங்கள் எதிர்பார்க்கும் நேரத்தில் இயங்கும்.

முதலில் ஒரு தவறான கருத்தை சரிசெய்ய வேண்டும். புதிதாக நிறுவப்பட்ட self-hosted n8n, UTC (coordinated universal time)-ல் இயங்குவதில்லை. அதிகாரப்பூர்வ image-ல் TZ அமைக்கப்படாததால், container clock UTC-ல் இருக்கும். Scheduling என்பது ஒரு தனி அடுக்கு; GENERIC_TIMEZONE-க்கான n8n-ன் ஆவணப்படுத்தப்பட்ட default மதிப்பு America/New_York (ஆகஸ்ட் 2026 நிலவரப்படி) ஆகும். எனவே, மாற்றங்கள் செய்யப்படாத ஒரு instance, தனது Schedule Triggers-ஐ New York நேரப்படி இயக்கும். இதனால்தான், பயனர்கள் குறிப்பிடும் நேர வித்தியாசம், அவர்களது உள்ளூர் நேரத்திற்கும் UTC-க்கும் இடையிலான வித்தியாசத்துடன் பொருந்துவதில்லை. உதாரணமாக, Berlin-ல் உள்ள ஒருவர் 06:00 மணிக்கு ஒரு செயலைத் திட்டமிட்டால், அது உள்ளூர் நேரப்படி 12:00 மணிக்கு இயங்கும். மார்ச் மாதத்தில் அமெரிக்கா daylight saving time-க்கு மாறியும், ஐரோப்பா மாறாதிருக்கும் வாரங்களில், இந்த நேரம் 11:00 மணியாக இருக்கும்.

மூன்று timezone அடுக்குகள் மற்றும் முன்னுரிமை பெறும் அடுக்கு

TZ என்பது container-க்குள் இருக்கும் operating system-ன் timezone ஆகும். n8n ஆவணங்களின்படி, இது system timezone-ஐ அமைக்கும் variable ஆகும்; இது date போன்ற scripts மற்றும் commands எதைக் காட்ட வேண்டும் என்பதைத் தீர்மானிக்கிறது. container-க்குள் date எதைக் காட்டுகிறது, container log-ல் எந்த timestamp பதிகிறது, Code node-ல் new Date() எதை வழங்குகிறது மற்றும் உள்ளே இயங்கும் shell script எதைப் பார்க்கிறது என்பதை இதுவே முடிவு செய்கிறது. Schedule Trigger எப்போது இயங்க வேண்டும் என்பதில் இதற்கு எந்தப் பங்கும் இல்லை.

GENERIC_TIMEZONE என்பது n8n instance timezone ஆகும். ஆவணங்கள் இதை n8n instance timezone என்று குறிப்பிடுகின்றன. Cron போன்ற scheduling nodes-க்கு இது முக்கியமானது. இங்கே Cron என்பது standard time-based scheduling syntax-ஐக் குறிக்கிறது; இதை n8n, Schedule Trigger-ல் Custom (Cron) விருப்பமாக வழங்குகிறது.

Workflow timezone ஒவ்வொரு workflow-க்கும் தனித்தனியாக அமைக்கப்படுகிறது. canvas-ல் workflow-ஐத் திறந்து, மேல் வலது மூலையில் உள்ள மூன்று புள்ளிகளைத் தேர்ந்தெடுத்து, Settings பகுதிக்குச் சென்று, Timezone மதிப்பை மாற்றவும். இது அந்த ஒரு குறிப்பிட்ட workflow-க்கு மட்டும் GENERIC_TIMEZONE-ஐ விட முன்னுரிமை பெறும்.

Schedule Trigger-க்கு, இந்த வரிசை நிலையானது. ஒரு workflow-க்கு timezone அமைக்கப்பட்டிருந்தால் n8n அதைப் பயன்படுத்தும்; இல்லையெனில் GENERIC_TIMEZONE-ல் உள்ள instance timezone-ஐப் பயன்படுத்தும்; அதுவும் இல்லையெனில் அதன் built-in default மதிப்பான America/New_York-ஐப் பயன்படுத்தும். இந்த முடிவெடுக்கும் எந்த நிலையிலும் TZ கணக்கில் கொள்ளப்படாது.

nodes-க்குள் இருக்கும் தேதிகளைப் பொறுத்தவரை, அந்த code எந்தக் கடிகாரத்தைக் கேட்கிறது என்பதைப் பொறுத்தே பதில் அமையும். n8n expressions-ன் பின்னணியில் உள்ள date library-ஆன Luxon, n8n timezone-ஐப் பயன்படுத்துகிறது. எனவே, $now மற்றும் $today ஆகியவை trigger-ஐப் போலவே workflow-then-instance என்ற வரிசையைப் பின்பற்றுகின்றன. Code node-ல் உள்ள சாதாரண JavaScript new Date(), operating system-ஐக் கேட்கிறது, எனவே அது TZ-ஐப் பின்பற்றுகிறது. இந்த வேறுபாடே குழப்பங்களுக்கு முக்கியக் காரணம்: trigger சரியாக இயங்கினாலும், workflow எழுதும் ஒவ்வொரு timestamp-ம் பல மணிநேரம் தள்ளி இருக்கலாம்.

Compose கோப்பில் மூன்றையும் அமைக்கவும்

TZ மற்றும் GENERIC_TIMEZONE ஆகியவற்றை கோப்பில் அருகருகே வைக்கவும், அப்போதுதான் ஒன்றை அமைத்துவிட்டு மற்றொன்றை மறக்க வாய்ப்பிருக்காது. கீழே உள்ள பகுதி, சரியாக இயங்கும் ஒரு service-ன் timezone தொடர்பான பகுதியாகும். கோப்பின் மற்ற பகுதிகள், reverse proxy மற்றும் certificate ஆகியவை HTTPS-க்கு பின்னால் உள்ள self-hosted n8n on a VPS என்பதிலிருந்து பெறப்படுகின்றன.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - GENERIC_TIMEZONE=Europe/Berlin
      - TZ=Europe/Berlin
      - N8N_RUNNERS_ENABLED=true
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

இதை docker compose restart மூலம் அல்லாமல், docker compose up -d மூலம் செயல்படுத்தவும். ஒரு restart என்பது ஏற்கனவே உருவாக்கப்பட்ட environment-உடன் அதே container-ஐ மீண்டும் தொடங்கும், எனவே கோப்பில் செய்யப்படும் மாற்றங்கள் இயங்கும் process-ல் பிரதிபலிக்காது. up -d மாற்றப்பட்ட environment-ஐக் கண்டறிந்து container-ஐ மீண்டும் உருவாக்கும். இந்த மதிப்புகளை inline-க்கு பதிலாக env கோப்பில் வைத்திருந்தாலும், அதே recreate விதி பொருந்தும், மேலும் Compose env file and secrets handling வழிகாட்டி அந்த கோப்பு எங்கிருந்து படிக்கப்படுகிறது என்பதை விளக்குகிறது.

Region/City வடிவத்தில், Europe/Berlin அல்லது America/Sao_Paulo போன்ற IANA (Internet Assigned Numbers Authority) zone பெயரைப் பயன்படுத்தவும். அந்தப் பெயர்கள் அந்த இடத்திற்கான daylight saving விதிகளைக் கொண்டுள்ளன, எனவே உள்ளூர் கடிகாரங்கள் மாறும்போது offset-ம் மாறும். Etc/GMT+5 போன்ற நிலையான-offset பெயர்கள் பருவங்களுக்கு ஏற்ப மாறாது, மேலும் அதன் குறியீடு (sign) நீங்கள் எதிர்பார்ப்பதற்கு நேர்மாறாக இருக்கும். LC_ALL=C TZ=Etc/GMT+5 date +%z கட்டளையை இயக்கினால் அது -0500 என்று அச்சிடும். அந்தப் பெயர்களைத் தவிர்க்கவும்.

ஏன் இரண்டில் ஒன்றை மட்டும் அமைப்பது பாதி தீர்வை மட்டுமே தரும்

GENERIC_TIMEZONE-ஐ மட்டும் அமைத்தால், Schedule Trigger நீங்கள் விரும்பிய நேரத்தில் இயங்கும், ஆனால் operating system-ஐ வாசிக்கும் மற்ற அனைத்தும் UTC-லேயே இருக்கும். new Date().toString()-ஐ அழைக்கும் Code node ஒரு UTC string-ஐத் தரும், container log வரிகள் UTC-ல் முத்திரையிடப்படும், மேலும் system clock-ஐக் கொண்டு உருவாக்கப்படும் எந்தவொரு கோப்புப் பெயரும் தவறான நள்ளிரவில் மாறும்.

TZ-ஐ மட்டும் அமைத்தால் இதற்கு நேர்மாறானது நடக்கும். docker compose exec n8n date உங்கள் உள்ளூர் நேரத்தைக் காட்டும், இது சரியாக வேலை செய்வது போலத் தோன்றும், ஆனால் Schedule Trigger இன்னும் America/New_York-லேயே இருக்கும் மற்றும் நீங்கள் கேட்ட நேரத்திலிருந்து ஆறு மணிநேரம் கழித்து இயங்கும். இந்த வகைதான் அதிக நேரத்தை வீணடிக்கும், ஏனெனில் பெரும்பாலானோர் முதலில் செய்யும் சரிபார்ப்பு இப்போது சரியாகத் தோன்றும்.

ஒரு workflow timezone-ஐ அமைத்துவிட்டு, பிறகு GENERIC_TIMEZONE-ஐ மாற்றினால், அந்த workflow மாற்றத்தைப் புறக்கணிக்கும். workflow-ல் உள்ள மதிப்பே முதன்மையானது, அந்த workflow-ன் அமைப்புகளை யாராவது திறக்கும் வரை அதுவே தொடரும். மற்ற workflow-கள் சரியாக இயங்கும்போது, ஒரு workflow மட்டும் விசித்திரமான நேரத்தில் இயங்குகிறது என்றால், அதற்கு பெரும்பாலும் இதுவே காரணமாக இருக்கும்.

ஊகிக்காமல் கடிகாரங்களைச் சரிபார்க்கவும்

Host மற்றும் container-ன் நேரத்தை நேரடியாக ஒப்பிடவும்.

date
docker compose exec n8n date
docker compose exec n8n printenv TZ GENERIC_TIMEZONE

TZ அமைக்கப்பட்ட பிறகு, முதல் இரண்டு கட்டளைகளும் ஒரே wall-clock நேரத்தைக் காட்ட வேண்டும். printenv ஒவ்வொரு variable-க்கும் ஒரு வரியை அச்சிடும்; எனவே, இரண்டு வரிகள் வந்தால் இரண்டும் அமைக்கப்பட்டுள்ளன என்று பொருள். ஒரு வரி மட்டுமே வந்தால், நீங்கள் பாதி சரிசெய்யப்பட்ட நிலையில் இருக்கிறீர்கள் என்று அர்த்தம்.

இப்போது n8n-இடம் அதன் workflow-க்குள் இருந்து கேட்கவும், ஏனெனில் container shell-ஆல் workflow-நிலை timezone என்ன என்பதைச் சொல்ல முடியாது. சரியாகச் செயல்படாத workflow-ல் ஒரு Code node-ஐச் சேர்த்து, அதை Execute Workflow மூலம் ஒருமுறை இயக்கவும்.

return [
  {
    json: {
      n8n_time: $now.toISO(),
      n8n_zone: $now.zoneName,
      system_time: new Date().toString(),
    },
  },
];

n8n_zone என்பது இந்த workflow-ன் Schedule Trigger பயன்படுத்தும் zone ஆகும். இது ஏற்கனவே workflow-then-instance வரிசையில் தீர்மானிக்கப்பட்டதால், இது நேரடியாக விடையைத் தரும். system_time என்பது TZ-லிருந்து பெறப்பட்ட container-ன் சொந்த zone-ஐக் குறிக்கும். இதை ஒரு புதிய workflow-ல் இயக்காமல், சரியாகச் செயல்படாத workflow-லேயே இயக்கவும், ஏனெனில் workflow-நிலை அமைப்புகள் அந்த workflow-உடன் பயணிக்கும். இந்த இரண்டு மதிப்புகளும் முரண்பட்டால், எந்தவொரு config file-ஐயும் திறக்காமலேயே நீங்கள் சிக்கலைக் கண்டறிந்துவிட்டீர்கள் என்று பொருள்.

Schedule Trigger node-ல் Cron expressions

Schedule Trigger வினாடிகள் முதல் மாதங்கள் வரையிலான நிலையான இடைவெளிகளை வழங்குகிறது. இவை போதாத பட்சத்தில், Custom (Cron) வசதியைப் பயன்படுத்தலாம். Workflow-ன் தீர்மானிக்கப்பட்ட timezone-ல் cron expression வாசிக்கப்படும். எனவே, 0 6 * * * என்பது UTC நேரத்திற்குப் பதிலாக அந்த குறிப்பிட்ட timezone-ல் 06:00 மணியைக் குறிக்கும். Crontab guru-விலிருந்து பெறப்படும் ஐந்து புலங்கள் கொண்ட expression-ஐ அப்படியே நகலெடுத்துப் பயன்படுத்தலாம். n8n வினாடிகளுக்கான விருப்பத்தேர்வு புலத்தையும் (seconds field) ஏற்கும். ஆவணங்களின் அட்டவணைப்படி இதன் வரிசை: second, minute, hour, day of month, month, day of week.

Offset-ஐ கைமுறையாக ஒருபோதும் குறியீடாக்க வேண்டாம். Berlin-ல் 06:00 மணியை அடைய UTC instance-ல் 0 4 * * * என்று எழுதுவது குளிர்காலத்தில் சரியாக இருக்கும், ஆனால் கோடைகாலத்தில் ஒரு மணிநேரம் தவறாக இருக்கும். ஏனெனில், Berlin குளிர்காலத்தில் UTC+1 மற்றும் கோடைகாலத்தில் UTC+2 நேரத்தைப் பின்பற்றுகிறது. எனவே, சரியான timezone-ஐ அமைத்து, உங்களுக்குத் தேவையான உள்ளூர் நேரத்தை (local hour) நேரடியாகக் குறிப்பிடவும்.

02:30-க்கு அமைக்கப்படும் வேலைகளில் பகல்நேர சேமிப்பு நேரம் (Daylight Saving) ஏற்படுத்தும் தாக்கம்

உள்ளூர் கடிகார நேரம் என்பது ஒரு நிலையான தருணம் அல்ல. ஆண்டுக்கு இருமுறை ஒரு மணிநேரம் மறைந்துபோகும் அல்லது மீண்டும் வரும்; அந்த நேரங்களுக்குள் திட்டமிடப்படும் எந்தவொரு வேலையும் இதனால் பாதிக்கப்படும். எந்தவொரு Linux கணினியிலும் n8n-ன் உதவியின்றி date கட்டளையைப் பயன்படுத்தி இதை நீங்கள் கண்காணிக்கலாம்.

LC_ALL=C TZ=Europe/Berlin date -d '2027-03-28 02:30'

date: invalid date '2027-03-28 02:30'

இந்தக் கட்டளையில் எந்த எழுத்துப் பிழையும் இல்லை. 2027-03-28 அன்று பெர்லின் கடிகாரம் 02:00 மணியிலிருந்து நேரடியாக 03:00 மணிக்கு மாறுகிறது. எனவே, அந்த நாளில் 02:30 என்ற உள்ளூர் நேரம் கிடையாது, மேலும் date அதை ஒரு குறிப்பிட்ட தருணமாக மாற்ற மறுத்துவிடும். 02:30 உள்ளூர் நேரத்திற்கு நிர்ணயிக்கப்பட்ட ஒரு வேலை இயங்குவதற்கு எந்த தருணமும் இருக்காது. அதற்கு அருகிலுள்ள நேரங்கள் சரியாகச் செயல்படும்: date -d '2027-03-28 01:30' என்பது CET ஆகவும், date -d '2027-03-28 03:30' என்பது CEST ஆகவும் மாறும்.

இலையுதிர் கால மாற்றம் இதற்கு நேர்மாறானது. 2027-10-31 அன்று பெர்லின் கடிகாரம் 03:00 மணியிலிருந்து 02:00 மணிக்கு பின்னோக்கிச் செல்லும், எனவே 02:30 என்ற நேரம் இருமுறை நிகழும்.

LC_ALL=C TZ=Europe/Berlin date -d '2027-10-31 02:30 CEST' '+%s'
LC_ALL=C TZ=Europe/Berlin date -d '2027-10-31 02:30 CET' '+%s'

1824942600
1824946200

இரண்டு வெவ்வேறு தருணங்கள், இவை இரண்டுமே 02:30 உள்ளூர் நேரம் என்று அழைக்கப்படுகின்றன, அவற்றுக்கிடையே 3600 வினாடிகள் இடைவெளி உள்ளது. அந்த நேரத்தில் நிர்ணயிக்கப்பட்ட ஒரு வேலை இருமுறை இயங்கலாம் அல்லது யாரும் தேர்ந்தெடுக்காத ஒரு நேரத்தில் ஒருமுறை இயங்கலாம். பில்லிங் ரன் (billing run) அல்லது பேக்கப் சுழற்சிக்கு (backup rotation) இந்த இரண்டு முடிவுகளுமே ஏற்புடையதல்ல. எனவே, அந்த நேர இடைவெளிக்கு வெளியே உங்கள் அட்டவணையை மாற்றி அமைக்கவும். பெரும்பாலான ஐரோப்பிய மற்றும் வட அமெரிக்க மண்டலங்களில், 00:00 முதல் 03:00 வரையிலான உள்ளூர் நேர இடைவெளி ஆபத்தானது.

உள்கட்டமைப்பை UTC-ல் திட்டமிட்டு, பயனர்களுக்கு உள்ளூர் நேரத்தைக் காட்டுதல்

ஒரு timezone செய்யும் இரண்டு பணிகளைப் பிரிப்பதே இதற்கான நிலையான தீர்வாகும். இயந்திரங்களுக்கு நிலையான கால இடைவெளி தேவை. மனிதர்களுக்கு வாசிக்கக்கூடிய நேரம் தேவை.

• யாரும் கவனிக்காத பணிகளுக்கு, workflow timezone-ஐ UTC-ல் அமைக்கவும். Backups, cache warming, log shipping மற்றும் report generation போன்றவை இதில் அடங்கும். UTC-ல் இரண்டு செயல்பாடுகளுக்கு இடைப்பட்ட காலம் நீங்கள் குறிப்பிட்டது போலவே துல்லியமாக இருக்கும், ஏனெனில் UTC-ல் daylight saving கிடையாது.
• மனிதர்கள் பார்க்கும் பணிகளுக்கு, அட்டவணையை UTC-ல் வைத்துக்கொண்டு, காட்டும் இடத்தில் மட்டும் மாற்றவும். ஒரே ஒரு expression இதைச் செய்யும்: {{ $now.setZone('Europe/Berlin').toFormat('yyyy-MM-dd HH:mm') }}, trigger நிலையாக இருக்கும்போதே message body-ல் உள்ளூர் நேரத்தைக் காட்டும்.

இதே பிரிவினை n8n-க்கு வெளியேயும் பொருந்தும். உங்கள் automation-ன் ஒரு பகுதி a systemd service and timer on the VPS ஆக இயங்கும்போது, அதன் OnCalendar வரி system timezone-ல் வாசிக்கப்படும்; இது தனியான அமைப்பைக் கொண்ட நான்காவது கடிகாரமாகும். அனைத்து scheduler-களையும் UTC-ல் வைத்திருப்பது, நான்கு விதிகளை நினைவில் கொள்வதற்குப் பதிலாக ஒரே ஒரு விதியை மட்டும் பின்பற்ற வழிவகுக்கும். ஒரு குறிப்பிட்ட கால அளவைச் சுருக்கிக் கூறும் பணிகளுக்கும் இது முக்கியமானது, ஏனெனில் an n8n AI agent workflow-விடம் நேற்றுக்கான தரவுகளைக் கேட்கும்போது, அது எந்த timezone-ஐப் பயன்படுத்துகிறதோ அதற்கேற்ப 24 மணிநேர கணக்கீடு மாறுபடும்.

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் வெளியீடு

அனைத்தும் ஆறு மணிநேரம் தள்ளி இயங்குகின்றன. GENERIC_TIMEZONE அமைக்கப்படவில்லை, எனவே உள்ளமைக்கப்பட்ட இயல்புநிலை America/New_York பயன்படுத்தப்படுகிறது. docker compose exec n8n printenv GENERIC_TIMEZONE எதையும் அச்சிடுவதில்லை. அதை அமைத்துவிட்டு, container-ஐ மீண்டும் உருவாக்கவும்.

நீங்கள் Compose கோப்பைத் திருத்தினீர்கள், ஆனால் எந்த மாற்றமும் இல்லை. நீங்கள் docker compose restart-ஐ இயக்கியுள்ளீர்கள், எனவே container அதன் பழைய சூழலையே தக்கவைத்துக் கொண்டது. docker compose up -d-ஐ இயக்கி, பின் docker compose exec n8n printenv TZ மூலம் உறுதிப்படுத்தவும்.

தூண்டுதல் (trigger) சரியாக உள்ளது, ஆனால் நேர முத்திரைகள் (timestamps) தவறாக உள்ளன. GENERIC_TIMEZONE மட்டுமே அமைக்கப்பட்டுள்ளது. Code node-ல் உள்ள new Date() இன்னும் இயங்குதளத்திலிருந்து UTC நேரத்தையே படிக்கிறது. TZ-ஐ அதே மதிப்பிற்கு அமைத்துவிட்டு, மீண்டும் உருவாக்கவும்.

ஒரு workflow instance அமைப்பைப் புறக்கணிக்கிறது. அந்த workflow அதன் சொந்த timezone அமைப்பைக் கொண்டுள்ளது, அது GENERIC_TIMEZONE-ஐ விட முன்னுரிமை பெறுகிறது. Canvas-ஐத் திறந்து, மூன்று புள்ளிகளை அழுத்தி, Settings, பின் Timezone பகுதிக்குச் செல்லவும்.

ஒரு தினசரி பணி இந்த ஆண்டில் ஒருமுறை இரண்டு முறை இயங்கியது அல்லது ஒரு நாளைத் தவிர்த்துவிட்டது. அதன் திட்டமிடப்பட்ட நேரம் பகல் சேமிப்பு நேர மாற்றத்திற்கு (daylight saving transition) இடையில் உள்ளது. அந்த நேரத்தை மாற்றவும் அல்லது அந்த workflow-ஐ UTC-க்கு மாற்றவும்.

FAQ

எனது n8n schedule trigger ஏன் தவறான நேரத்தில் இயங்குகிறது?

நீங்கள் கருதுவதை விட workflow வேறு ஒரு timezone-ஐப் பயன்படுத்துகிறது. workflow-க்கு என்று தனி timezone இருந்தால் n8n அதைப் பயன்படுத்தும்; இல்லையெனில் GENERIC_TIMEZONE-ல் உள்ள instance timezone-ஐப் பயன்படுத்தும்; அதுவும் இல்லையெனில் அதன் இயல்பான America/New_York-ஐப் பயன்படுத்தும். GENERIC_TIMEZONE அமைக்கப்படாத ஒரு self-hosted instance, UTC-க்கு பதிலாக New York நேரத்தையே பயன்படுத்தும். இதனால்தான் உங்கள் UTC நேரத்திற்கும் இதற்கும் உள்ள வேறுபாடு சரியாக இருப்பதில்லை. docker compose exec n8n printenv GENERIC_TIMEZONE கட்டளையை இயக்கவும். எந்த வெளியீடும் வரவில்லை என்றால், அது அமைக்கப்படவில்லை என்று பொருள்.

n8n-ல் TZ மற்றும் GENERIC_TIMEZONE ஆகியவற்றிற்கு என்ன வித்தியாசம்?

TZ என்பது container-க்குள் இருக்கும் operating system-ன் timezone ஆகும். இது container-க்குள் date எதைக் காட்டுகிறது, container log வரிகளில் என்ன timestamp வருகிறது, Code node-ல் new Date() எதைக் காட்டுகிறது மற்றும் நீங்கள் இயக்கும் script-கள் எதைப் பார்க்கின்றன என்பதைத் தீர்மானிக்கிறது. GENERIC_TIMEZONE என்பது n8n instance-ன் timezone ஆகும். இதுதான் schedule nodes மற்றும் $now போன்ற Luxon expressions-க்கு அடிப்படையாகும். இரண்டில் ஒன்றை மட்டும் அமைத்தால், trigger சரியாக இருந்து timestamp தவறாக இருக்கும், அல்லது timestamp சரியாக இருந்து trigger தவறான நேரத்தில் இயங்கும். இரண்டையும் ஒரே மதிப்பில் அமைக்கவும்.

நான் workflow timezone-ஐ அமைக்க வேண்டுமா அல்லது GENERIC_TIMEZONE-ஐ அமைக்க வேண்டுமா?

முழு instance-க்கும் பொதுவான அமைப்பாக GENERIC_TIMEZONE-ஐ அமைக்கவும். ஒரு குறிப்பிட்ட workflow மட்டும் வேறு timezone-ல் இயங்க வேண்டியிருந்தால் மட்டுமே, அந்த workflow-க்கான தனி அமைப்பைப் பயன்படுத்தவும். workflow-ன் மதிப்பு instance-ன் மதிப்பை விட முன்னுரிமை பெறும். மேலும், இது GENERIC_TIMEZONE-ல் செய்யப்படும் மாற்றங்களைப் பின்பற்றாது. எனவே, ஒரு workflow-க்கு மட்டும் மாற்றப்பட்ட அமைப்பை மாதங்கள் கழித்து கண்டறிவது கடினம்.

கடிகார நேரம் மாறும்போது 02:30-க்கு திட்டமிடப்பட்ட வேலைக்கு என்னவாகும்?

அந்த உள்ளூர் நேரம் ஒன்று இல்லாமல் போகும் அல்லது இரண்டு முறை நிகழும். பெர்லின் கடிகாரம் அன்று 02:00-லிருந்து 03:00-க்கு மாறுவதால், LC_ALL=C TZ=Europe/Berlin date -d '2027-03-28 02:30' என்பது date: invalid date '2027-03-28 02:30'-ஐத் தரும். 2027-10-31 அன்று, ஒரே கடிகார நேரம் ஒரு மணிநேர இடைவெளியில் இரண்டு வெவ்வேறு தருணங்களைக் குறிக்கும். திட்டமிடப்பட்ட வேலைகளை 00:00 முதல் 03:00 வரையிலான உள்ளூர் நேரத்திற்குள் வைக்காதீர்கள். அல்லது workflow-ஐ UTC-ல் வைத்துவிட்டு, மனிதர்கள் பார்க்கும் இடத்தில் மட்டும் உள்ளூர் நேரத்திற்கு மாற்றிக்கொள்ளுங்கள்.