n8n schedule trigger ভুল সময়ে কাজ করার সমাধান

কেন আপনার n8n schedule trigger ভুল সময়ে কাজ করে

n8n-এর schedule trigger ভুল সময়ে কাজ করার কারণ হলো n8n তিনটি ভিন্ন জায়গা থেকে তার timezone পড়ে, এবং এর মধ্যে একটি ঠিক করলে সমস্যার আংশিক সমাধান হয় মাত্র। এই তিনটি জায়গা হলো কন্টেইনারের নিজস্ব TZ ভেরিয়েবল, ইনস্ট্যান্সের ডিফল্ট GENERIC_TIMEZONE, এবং প্রতিটি ওয়ার্কফ্লোর ভেতরে সেট করা timezone। এই তিনটিই একবার সঠিকভাবে সেট করে নিলে পরবর্তীতে আপনার তৈরি করা প্রতিটি শিডিউল প্রত্যাশিত সময়েই কাজ করবে।

প্রথমে একটি ভুল ধারণা সংশোধন করুন। একটি নতুন self-hosted n8n ইনস্ট্যান্স UTC (coordinated universal time)-এ শিডিউল করে না। কন্টেইনারের ঘড়িটি UTC-তে থাকে, কারণ অফিসিয়াল ইমেজে কোনো TZ সেট করা থাকে না। শিডিউলিং একটি আলাদা স্তর, এবং GENERIC_TIMEZONE-এর জন্য n8n-এর নথিবদ্ধ ডিফল্ট হলো America/New_York (আগস্ট 2026 অনুযায়ী), তাই কোনো পরিবর্তন না করা ইনস্ট্যান্স তার Schedule Trigger-গুলোকে নিউ ইয়র্কের সময় অনুযায়ী চালায়। এই কারণেই ব্যবহারকারীরা যে সময়ের পার্থক্য লক্ষ্য করেন, তা তাদের নিজেদের স্থানীয় সময়ের সাথে UTC-এর পার্থক্যের সাথে খুব কমই মিলে। বার্লিনের একজন ব্যবহারকারী যদি 06:00-এর জন্য শিডিউল করেন, তবে সেটি স্থানীয় সময় 12:00-তে কাজ করবে, এবং মার্চের সেই সপ্তাহগুলোতে 11:00-তে কাজ করবে যখন যুক্তরাষ্ট্রে daylight saving time শুরু হয় কিন্তু ইউরোপে তা হয়নি।

তিনটি টাইমজোন লেয়ার এবং কোনটি কার্যকর হয়

TZ হলো কন্টেইনারের ভেতরে থাকা অপারেটিং সিস্টেমের টাইমজোন। n8n ডকুমেন্টেশন অনুযায়ী, এটি এমন একটি ভেরিয়েবল যা সিস্টেম টাইমজোন সেট করে এবং date-এর মতো স্ক্রিপ্ট ও কমান্ডগুলো কী আউটপুট দেবে তা নিয়ন্ত্রণ করে। এটি নির্ধারণ করে কন্টেইনারের ভেতরে date কী প্রিন্ট করবে, কন্টেইনার লগ লাইনে কী টাইমস্ট্যাম্প থাকবে, Code নোডে new Date() কী রিটার্ন করবে এবং সেখানে চালানো যেকোনো শেল স্ক্রিপ্ট কী দেখবে। Schedule Trigger কখন কাজ শুরু করবে, তার ওপর এর কোনো প্রভাব নেই।

GENERIC_TIMEZONE হলো n8n ইনস্ট্যান্সের টাইমজোন। ডকুমেন্টেশনে একে n8n ইনস্ট্যান্স টাইমজোন বলা হয়েছে এবং উল্লেখ করা হয়েছে যে এটি Cron-এর মতো শিডিউল নোডের জন্য গুরুত্বপূর্ণ। এখানে Cron বলতে স্ট্যান্ডার্ড টাইম-বেসড শিডিউলিং সিনট্যাক্স বোঝায় এবং n8n এটিকে Schedule Trigger-এ Custom (Cron) অপশন হিসেবে প্রদর্শন করে।

ওয়ার্কফ্লো টাইমজোন প্রতিটি ওয়ার্কফ্লোর জন্য আলাদাভাবে সেট করা হয়। ক্যানভাসে ওয়ার্কফ্লোটি ওপেন করুন, উপরের ডানদিকের তিনটি ডটে ক্লিক করুন, Settings নির্বাচন করুন এবং তারপর Timezone-এর মান পরিবর্তন করুন। এটি নির্দিষ্ট ওই ওয়ার্কফ্লোর জন্য GENERIC_TIMEZONE-কে ওভাররাইড করে।

Schedule Trigger-এর ক্ষেত্রে অগ্রাধিকারের ক্রম নির্দিষ্ট। যদি ওয়ার্কফ্লোতে কোনো টাইমজোন সেট করা থাকে, তবে n8n সেটি ব্যবহার করে; অন্যথায় GENERIC_TIMEZONE থেকে ইনস্ট্যান্স টাইমজোন ব্যবহার করে; আর তাও না থাকলে এর বিল্ট-ইন ডিফল্ট America/New_York ব্যবহার করে। এই সিদ্ধান্তের কোনো ধাপেই TZ বিবেচনা করা হয় না।

নোডের ভেতরে তারিখের ক্ষেত্রে, উত্তরটি নির্ভর করে কোড কোন ঘড়ি থেকে তথ্য নিচ্ছে তার ওপর। n8n এক্সপ্রেশনের পেছনে থাকা ডেট লাইব্রেরি Luxon, n8n টাইমজোন ব্যবহার করে। তাই $now এবং $today ট্রিগারের মতোই ওয়ার্কফ্লো-তারপর-ইনস্ট্যান্স ক্রম অনুসরণ করে। Code নোডে সাধারণ JavaScript new Date() অপারেটিং সিস্টেমের কাছে জানতে চায়, তাই এটি TZ অনুসরণ করে। এই বিভাজনই বেশিরভাগ বিভ্রান্তির মূল কারণ: ট্রিগারটি সঠিক হতে পারে, কিন্তু ওয়ার্কফ্লোতে লেখা প্রতিটি টাইমস্ট্যাম্প কয়েক ঘণ্টা এগিয়ে বা পিছিয়ে থাকতে পারে।

Compose ফাইলে তিনটিই সেট করুন

ফাইলে TZ এবং GENERIC_TIMEZONE-কে পাশাপাশি রাখুন, যাতে কেউ একটি সেট করে অন্যটি ভুলে না যায়। নিচের অংশটি একটি কার্যকর সার্ভিসের টাইমজোন-সংক্রান্ত অংশ। ফাইলের বাকি অংশ, রিভার্স প্রক্সি এবং সার্টিফিকেট 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 দিয়ে প্রয়োগ করুন। একটি রিস্টার্ট একই কন্টেইনারকে তার পুরনো এনভায়রনমেন্টসহ পুনরায় চালু করে, তাই ফাইলের পরিবর্তন চলমান প্রসেসে কার্যকর হয় না। up -d পরিবর্তিত এনভায়রনমেন্ট শনাক্ত করে এবং কন্টেইনারটি পুনরায় তৈরি (recreate) করে। আপনি যদি এই ভ্যালুগুলো ইনলাইনের পরিবর্তে একটি env ফাইলে রাখেন, তবে একই রিক্রিয়েট নিয়ম প্রযোজ্য হবে এবং Compose env file and secrets handling গাইডটি দেখুন যে সেই ফাইলটি কোথা থেকে পড়া হয়।

Region/City ফরম্যাটে একটি IANA (Internet Assigned Numbers Authority) জোন নাম ব্যবহার করুন, যেমন Europe/Berlin বা America/Sao_Paulo। এই নামগুলো সেই স্থানের জন্য ডে-লাইট সেভিং নিয়মগুলো বহন করে, তাই স্থানীয় ঘড়ির পরিবর্তনের সাথে সাথে অফসেটও পরিবর্তিত হয়। Etc/GMT+5-এর মতো একটি নির্দিষ্ট-অফসেট নাম ঋতু পরিবর্তনের সাথে পরিবর্তিত হয় না এবং এর চিহ্নটি আপনার ধারণার বিপরীত হয়। LC_ALL=C TZ=Etc/GMT+5 date +%z রান করলে এটি -0500 প্রিন্ট করে। এই নামগুলো এড়িয়ে চলুন।

কেন শুধুমাত্র একটি সেট করলে সমস্যার অর্ধেক সমাধান হয়

শুধুমাত্র GENERIC_TIMEZONE সেট করলে Schedule Trigger আপনার কাঙ্ক্ষিত সময়েই কাজ শুরু করে, কিন্তু অপারেটিং সিস্টেমের ওপর নির্ভরশীল সবকিছু UTC-তেই থেকে যায়। কোনো Code node থেকে new Date().toString() কল করলে তা একটি UTC স্ট্রিং প্রদান করে, কন্টেইনারের লগ লাইনগুলো UTC টাইমস্ট্যাম্পে থাকে এবং সিস্টেম ক্লক ব্যবহার করে তৈরি করা যেকোনো ফাইলের নাম ভুল সময়ে (মধ্যরাতে) পরিবর্তিত হয়ে যায়।

শুধুমাত্র TZ সেট করলে এর বিপরীতটি ঘটে। docker compose exec n8n date আপনার লোকাল টাইম প্রদর্শন করে, যা দেখে মনে হয় সবকিছু ঠিক আছে, কিন্তু Schedule Trigger তখনও America/New_York-এ থাকে এবং আপনার নির্ধারিত সময়ের ছয় ঘণ্টা পরে কাজ শুরু করে। এই সমস্যাটি সমাধান করতে সবচেয়ে বেশি সময় নষ্ট হয়, কারণ বেশিরভাগ মানুষ প্রথমে যে পরীক্ষাটি চালায়, সেটি তখন সফল দেখায়।

একটি workflow timezone সেট করার পর পরবর্তীতে যদি GENERIC_TIMEZONE পরিবর্তন করেন, তবে সেই workflow নতুন পরিবর্তনটিকে উপেক্ষা করবে। workflow-এর নিজস্ব ভ্যালুটিই কার্যকর থাকে এবং যতক্ষণ না কেউ সেই workflow-এর সেটিংসে গিয়ে পরিবর্তন করছে, ততক্ষণ সেটিই বজায় থাকে। যদি দেখেন কোনো একটি workflow অদ্ভুত সময়ে চলছে অথচ তার পাশের workflow-গুলো ঠিকঠাক কাজ করছে, তবে প্রায় সবসময়ই এর কারণ এটি।

অনুমান না করে ঘড়ির সময় পরীক্ষা করুন

সরাসরি হোস্ট এবং কন্টেইনারের সময় তুলনা করুন।

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

TZ সেট করা থাকলে প্রথম দুটি কমান্ড একই ওয়াল-ক্লক টাইম প্রদর্শন করবে। printenv প্রতিটি বিদ্যমান ভেরিয়েবলের জন্য একটি লাইন প্রিন্ট করে, তাই আউটপুটে দুটি লাইন থাকা মানে উভয়ই সেট করা আছে, আর একটি লাইন থাকা মানে আপনি আংশিক কনফিগার করা অবস্থায় আছেন।

এখন n8n-এর ভেতর থেকে একটি ওয়ার্কফ্লো ব্যবহার করে সরাসরি n8n-কে জিজ্ঞাসা করুন, কারণ কন্টেইনারের শেল আপনাকে ওয়ার্কফ্লো-লেভেলের টাইমজোন সম্পর্কে সঠিক তথ্য দিতে পারবে না। যে ওয়ার্কফ্লোটি সঠিকভাবে কাজ করছে না তাতে একটি Code নোড যোগ করুন এবং Execute Workflow ব্যবহার করে একবার চালান।

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

n8n_zone হলো সেই জোন যা এই ওয়ার্কফ্লোর Schedule Trigger ব্যবহার করবে, যা ওয়ার্কফ্লো এবং ইনস্ট্যান্সের অগ্রাধিকার অনুযায়ী নির্ধারিত হয়, তাই এটি সরাসরি আপনার প্রশ্নের উত্তর দেয়। system_time কন্টেইনারের নিজস্ব জোন বহন করে যা TZ থেকে আসে। এটি নতুন কোনো ওয়ার্কফ্লোতে না চালিয়ে সমস্যাযুক্ত ওয়ার্কফ্লোতেই চালান, কারণ ওয়ার্কফ্লো-লেভেলের সেটিংস ওয়ার্কফ্লোর সাথেই থাকে। যদি এই দুটি মান ভিন্ন হয়, তবে কোনো কনফিগারেশন ফাইল না খুলেই আপনি সমস্যার উৎস খুঁজে পেয়েছেন।

Schedule Trigger নোডে Cron এক্সপ্রেশন

Schedule Trigger সেকেন্ড থেকে শুরু করে মাস পর্যন্ত নির্দিষ্ট বিরতির সুবিধা দেয়। এছাড়া, যেসব ক্ষেত্রে এই বিরতিগুলো যথেষ্ট নয়, সেখানে Custom (Cron) ব্যবহার করা যায়। Cron এক্সপ্রেশনটি ওয়ার্কফ্লোর নির্ধারিত টাইমজোন অনুযায়ী পড়া হয়, তাই 0 6 * * * বলতে সেই জোনের সকাল 06:00 বোঝায়, UTC-এর সকাল 06:00 নয়। crontab guru থেকে নেওয়া পাঁচ-ফিল্ডের এক্সপ্রেশন এখানে সরাসরি পেস্ট করা যায়। n8n ঐচ্ছিক সেকেন্ড ফিল্ডও গ্রহণ করে, যা ডকুমেন্টেশনের ফিল্ড টেবিলে সবার আগে থাকে: second, minute, hour, day of month, month, day of week।

কখনও নিজে থেকে অফসেট এনকোড করবেন না। বার্লিনের সকাল 06:00 পাওয়ার জন্য UTC ইনস্ট্যান্সে 0 4 * * * লেখা শীতকালে সঠিক হলেও গ্রীষ্মকালে এক ঘণ্টা ভুল হবে, কারণ বার্লিন শীতকালে UTC+1 এবং গ্রীষ্মকালে UTC+2 তে চলে। সঠিক জোন সেট করুন এবং আপনি যে স্থানীয় সময়টি বোঝাতে চাচ্ছেন সেটি লিখুন।

ডে-লাইট সেভিং টাইম 02:30-এ নির্ধারিত কাজের ওপর কী প্রভাব ফেলে

স্থানীয় ঘড়ির সময় কোনো নির্দিষ্ট মুহূর্তের নিশ্চয়তা দেয় না। বছরে দুবার এক ঘণ্টা হারিয়ে যায় এবং এক ঘণ্টা পুনরাবৃত্তি হয়, আর এই সময়ের মধ্যে নির্ধারিত যেকোনো কাজ প্রভাবিত হয়। আপনি যেকোনো Linux বক্সে date ব্যবহার করে এটি ঘটতে দেখতে পারেন, যেখানে n8n-এর কোনো ভূমিকা নেই।

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 সেকেন্ডের ব্যবধান থাকে। সেখানে নির্ধারিত কোনো কাজ হয় দুবার চলবে অথবা এমন এক সময়ে চলবে যা কেউ নির্বাচন করেনি, আর বিলিং রান বা ব্যাকআপ রোটেশনের জন্য এর কোনোটিই কাঙ্ক্ষিত নয়। আপনার শিডিউলটি এই সময়ের বাইরে সরিয়ে নিন। ইউরোপ এবং উত্তর আমেরিকার বেশিরভাগ অঞ্চলে ঝুঁকিপূর্ণ সময়সীমা হলো স্থানীয় 00:00 থেকে 03:00।

ইনফ্রাস্ট্রাকচারের শিডিউল UTC-তে রাখুন এবং ব্যবহারকারীদের জন্য লোকাল টাইম দেখান

একটি টাইমজোন যে দুটি কাজ করে, আদর্শ সমাধান সেই দুটিকে আলাদা করে ফেলে। মেশিনের জন্য প্রয়োজন একটি স্থিতিশীল বিরতি। মানুষের জন্য প্রয়োজন একটি বোধগম্য সময়।

• যে কাজগুলো কেউ সরাসরি পর্যবেক্ষণ করে না, সেগুলোর ওয়ার্কফ্লো টাইমজোন UTC-তে সেট করুন। ব্যাকআপ, ক্যাশ ওয়ার্মিং, লগ শিপিং এবং রিপোর্ট জেনারেশনের কাজগুলো এই ক্যাটাগরিতে পড়ে। UTC-তে দুটি কাজের মধ্যবর্তী সময়ের ব্যবধান সবসময় আপনার লেখা ব্যবধানের সমান থাকে, কারণ UTC-তে কোনো daylight saving নেই।
• যে কাজগুলো মানুষ দেখে, সেগুলোর শিডিউল UTC-তে রাখুন এবং প্রদর্শনের সময় তা রূপান্তর করুন। একটি এক্সপ্রেশনই এটি করতে পারে: {{ $now.setZone('Europe/Berlin').toFormat('yyyy-MM-dd HH:mm') }} মেসেজ বডিতে লোকাল টাইম দেখায়, অথচ ট্রিগারটি স্থিতিশীল থাকে।

একই বিভাজন n8n-এর বাইরেও প্রযোজ্য। যখন আপনার অটোমেশনের কোনো অংশ VPS-এ systemd service এবং timer হিসেবে চলে, তখন এর OnCalendar লাইনটি সিস্টেম টাইমজোনে পড়া হয়, যা নিজস্ব সেটিংসসহ চতুর্থ একটি ঘড়ি হিসেবে কাজ করে। প্রতিটি শিডিউলারকে UTC-তে রাখলে আপনাকে চারটি আলাদা নিয়মের পরিবর্তে মাত্র একটি নিয়ম মনে রাখতে হয়। এটি এমন যেকোনো কাজের ক্ষেত্রে গুরুত্বপূর্ণ যা একটি নির্দিষ্ট সময়কালকে সারসংক্ষেপ করে, কারণ একটি n8n AI agent workflow-কে গতকালের ডেটা চাইলে সেটি কোন টাইমজোন অনুযায়ী কাজ করছে তার ওপর ভিত্তি করে 24 ঘণ্টার হিসাব ভিন্ন হতে পারে।

ব্যর্থতার ধরন এবং আপনি যে আউটপুট দেখবেন

সবকিছু ছয় ঘণ্টা দেরিতে কার্যকর হচ্ছে। GENERIC_TIMEZONE কখনোই সেট করা হয়নি, তাই বিল্ট-ইন ডিফল্ট America/New_York কার্যকর হচ্ছে। docker compose exec n8n printenv GENERIC_TIMEZONE কোনো কিছুই প্রিন্ট করে না। এটি সেট করুন, তারপর কন্টেইনারটি পুনরায় তৈরি করুন।

আপনি Compose ফাইল এডিট করেছেন কিন্তু কোনো পরিবর্তন হয়নি। আপনি docker compose restart চালিয়েছেন, তাই কন্টেইনারটি তার আগের এনভায়রনমেন্ট ধরে রেখেছে। docker compose up -d চালান, তারপর docker compose exec n8n printenv TZ দিয়ে নিশ্চিত করুন।

ট্রিগার সঠিক কিন্তু টাইমস্ট্যাম্প ভুল দেখাচ্ছে। শুধুমাত্র GENERIC_TIMEZONE সেট করা আছে। একটি Code নোডের ভেতরের new Date() এখনো অপারেটিং সিস্টেম থেকে UTC সময় পড়ছে। TZ-কে একই মানে সেট করুন এবং পুনরায় তৈরি করুন।

একটি ওয়ার্কফ্লো ইনস্ট্যান্সের সেটিং উপেক্ষা করছে। সেই ওয়ার্কফ্লোর নিজস্ব সেটিংসে আলাদা টাইমজোন দেওয়া আছে, যা GENERIC_TIMEZONE-এর চেয়ে বেশি প্রাধান্য পায়। ক্যানভাস খুলুন, তিনটি ডটে ক্লিক করুন, তারপর Settings থেকে Timezone-এ যান।

এই বছর একটি ডেইলি জব দুইবার চলেছে অথবা একদিন বাদ পড়েছে। এর নির্ধারিত সময়টি ডে-লাইট সেভিং পরিবর্তনের ভেতরে পড়ে গেছে। সময় পরিবর্তন করুন, অথবা সেই ওয়ার্কফ্লোটিকে UTC-তে স্থানান্তর করুন।

FAQ

আমার n8n শিডিউল ট্রিগার কেন ভুল সময়ে কাজ করে?

ওয়ার্কফ্লোটি আপনার ধারণার চেয়ে ভিন্ন টাইমজোন ব্যবহার করছে। যদি ওয়ার্কফ্লোতে কোনো টাইমজোন সেট করা থাকে, তবে n8n সেটিই গ্রহণ করে। অন্যথায় এটি GENERIC_TIMEZONE থেকে ইনস্ট্যান্সের টাইমজোন নেয়, আর তাও না থাকলে ডিফল্ট হিসেবে America/New_York ব্যবহার করে। একটি সেলফ-হোস্টেড ইনস্ট্যান্সে যেখানে কেউ GENERIC_TIMEZONE সেট করেননি, সেখানে শিডিউলগুলো নিউ ইয়র্ক টাইম অনুযায়ী চলে, UTC অনুযায়ী নয়। এই কারণেই আপনার স্থানীয় সময়ের সাথে এর পার্থক্যের মিল পাওয়া যায় না। docker compose exec n8n printenv GENERIC_TIMEZONE কমান্ডটি চালিয়ে দেখুন। কোনো আউটপুট না আসা মানে হলো এটি কখনোই সেট করা হয়নি।

n8n-এ TZ এবং GENERIC_TIMEZONE-এর মধ্যে পার্থক্য কী?

TZ হলো কন্টেইনারের ভেতরে থাকা অপারেটিং সিস্টেমের টাইমজোন। এটি নিয়ন্ত্রণ করে কন্টেইনারের ভেতরে date কী রিটার্ন করবে, কন্টেইনার লগের টাইমস্ট্যাম্প কেমন হবে, Code নোডে new Date() কী আউটপুট দেবে এবং সেখানে চালানো যেকোনো স্ক্রিপ্ট কী দেখতে পাবে। GENERIC_TIMEZONE হলো n8n ইনস্ট্যান্সের টাইমজোন, যা শিডিউল নোড এবং $now-এর মতো Luxon এক্সপ্রেশনগুলো ব্যবহার করে। একটি সেট করে অন্যটি না করলে আপনি হয় ভুল টাইমস্ট্যাম্পসহ সঠিক ট্রিগার পাবেন, অথবা সঠিক টাইমস্ট্যাম্পসহ এমন ট্রিগার পাবেন যা ভুল সময়ে কাজ করে। তাই উভয়কেই একই মানে সেট করুন।

আমার কি ওয়ার্কফ্লো টাইমজোন সেট করা উচিত নাকি GENERIC_TIMEZONE?

পুরো ইনস্ট্যান্সের ডিফল্ট হিসেবে GENERIC_TIMEZONE সেট করুন। শুধুমাত্র তখনই ওয়ার্কফ্লো-ভিত্তিক সেটিংস ব্যবহার করুন যখন কোনো নির্দিষ্ট ওয়ার্কফ্লো অন্য কোনো টাইমজোনের সাথে সম্পর্কিত হয়। ওয়ার্কফ্লোর মান ইনস্ট্যান্সের মানের চেয়ে অগ্রাধিকার পায় এবং এটি পরবর্তীতে GENERIC_TIMEZONE-এ করা পরিবর্তন অনুসরণ করে না। ফলে ওয়ার্কফ্লো-ভিত্তিক কোনো ওভাররাইড ভুলে গেলে কয়েক মাস পর তা খুঁজে বের করা কঠিন হয়ে পড়ে।

ঘড়ির সময় পরিবর্তনের সময় 02:30-এ শিডিউল করা কাজের কী হয়?

সেই স্থানীয় সময় হয় অদৃশ্য হয়ে যায় অথবা দুইবার ঘটে। LC_ALL=C TZ=Europe/Berlin date -d '2027-03-28 02:30' তখন date: invalid date '2027-03-28 02:30' রিটার্ন করে, কারণ বার্লিনের ঘড়ি সেই দিন 02:00 থেকে সরাসরি 03:00-তে চলে যায়। 2027-10-31 তারিখে একই ঘড়ির সময় এক ঘণ্টার ব্যবধানে দুটি ভিন্ন মুহূর্তকে নির্দেশ করে। শিডিউল করা কাজগুলোকে স্থানীয় সময়ের 00:00 থেকে 03:00-এর মধ্যে রাখা থেকে বিরত থাকুন, অথবা ওয়ার্কফ্লোকে UTC-তে সেট করুন এবং শুধুমাত্র যেখানে মানুষ তা দেখবে, সেখানে স্থানীয় সময়ে রূপান্তর করুন।