تصویر ذخیره‌شده از جلسه‌های معاملاتی می‌تواند دقیقاً یک ساعت شما را گمراه کند — و این کار را کاملاً مطمئن انجام دهد. لندن، نیویورک و سیدنی ساعت را طبق تقویم‌های متفاوت تغییر میدهند و پلتفرم معامله‌ها را طبق برنامهی خودش می‌پذیرد. زمان جلسه‌های معاملاتی Forex را به UTC بررسی می‌کنیم، تبدیل آن را برای مناطق مختلف نشان می‌دهیم و یک پنجرهی کاری مشاهده در intrade.bar می‌سازیم. اینجا ساعت‌ها به سازمان‌دهی تحلیل کمک می‌کنند، نه این‌که سود طبق جدول وعده دهند.
جلسهی معاملاتی را چه می‌نامند
بازار ارز ساختمان واحدی ندارد که صبح در آن زنگ بزنند و همهی نرخ‌ها روشن شوند. شرکتکنندگان در مراکز مالی مختلف کار می‌کنند و فعالیت همراه با روز کاری آن‌ها جابه‌جا می‌شود. نام‌های جلسهی «آسیایی»، «لندنی» و «آمریکایی» به توصیف این دوره‌ها کمک می‌کنند.
به همین دلیل دو جدول حتی در یک منطقه‌ی زمانی هم ممکن است متفاوت باشند. یک نویسنده آغاز روز کاری بانک‌ها را گرفته، دیگری پنجرهی گسترده‌تری به کار برده و سومی چند مرکز را ترکیب کرده است. پیش از بحث بر سر زمان درست، تعریف‌های اولیه را مقایسه کنید. عنوان «زمان Forex» بدون تاریخ و توضیح برای یک برنامهی دقیق بسیار کلی است.
در دسترس بودن محصول معاملاتی موضوع جداگانه‌ای است. جدول متغیر تضمین نمی‌کند الآن بتوان هر اختیار معامله‌ی دیجیتال روی این دارایی را باز کرد. پلتفرم ممکن است وقفه، محدودیت مدت و شرایط بازده داشته باشد. برای intrade.bar تقویم مراکز مالی زمینه‌ی مشاهده است؛ جفت‌ارز در دسترس و پارامترهای معامله مستقیماً در ترمینال بررسی می‌شوند.
یک مدل روشن برای تبدیل
در این مقاله از پنجرهی آموزشی 08:00–17:00 به وقت محلی هر مرکز استفاده می‌کنیم. این پنجره مدعی برنامهی جهانی کل Forex نیست. وظیفه‌اش ارائه‌ی یک قرارداد اولیه‌ی یکسان است که بر اساس آن بتوان تبدیل به UTC و سپس به وقت محلی خودتان را بررسی کرد.
اگر تقویم شما جلسهی توکیو یا سیدنی را متفاوت علامت می‌زند، مرزهای محلی آن را جایگزین کنید و همان تبدیل را انجام دهید. نمی‌توان ساعتهای جدول را مستقیم به برنامهی intrade.bar، فیوچرز بورسی یا یک بانک مشخص منتقل کرد. نام یکسان شهر این رژیم‌ها را یکسان نمی‌کند.
UTC به ساعت تابستانی نمی‌رود. نسبت ساعت محلی با این مقیاس تغییر میکند: لندن گاهی GMT و گاهی BST است، نیویورک EST و EDT، سیدنی AEST و AEDT. عبارت «نیویورک، UTC−5» برای یک رژیم درست است، نه برای کل سال. در تقویم بهتر است نام منطقه‌ی زمانی را نگه دارید، نه فقط انحراف امروز را.
جدول جلسه‌ها به UTC: ژانویه و ژوئیه‌ی 2026
در زیر پنجرهی انتخابی 08:00–17:00 برای یک روز عادی هفته در دو ماه بازمحاسبه شده است. عبارت «روز قبل» یعنی تاریخ تقویمی قبلی به UTC. مثلاً صبح محلی دوشنبه در سیدنی روی مقیاس زمانی مشترک از غروب یکشنبه شروع می‌شود.
| مرکز | پنجرهی محلی مدل | ژانویه‌ی 2026 به UTC | ژوئیه‌ی 2026 به UTC |
|---|---|---|---|
| سیدنی | 08:00–17:00 | 21:00 روز قبل – 06:00 | 22:00 روز قبل – 07:00 |
| توکیو | 08:00–17:00 | 23:00 روز قبل – 08:00 | 23:00 روز قبل – 08:00 |
| لندن | 08:00–17:00 | 08:00–17:00 | 07:00–16:00 |
| نیویورک | 08:00–17:00 | 13:00–22:00 | 12:00–21:00 |
در ژانویه سیدنی از UTC+11 و در ژوئیه از UTC+10 استفاده میکند. برای لندن مقدارهای مربوط UTC+0 و UTC+1 و برای نیویورک UTC−5 و UTC−4 است. توکیو UTC+9 می‌ماند. ساعتهای جدول از همین انحراف‌ها به دست می‌آیند: به وقت محلی انحراف با علامت مخالف را اضافه می‌کنید.
ماه‌ها در اینجا از واژه‌های «زمستان» و «تابستان» دقیق‌ترند. در ژانویه در بریتانیا زمستان است و در استرالیا تابستان. برای مخاطب بین‌المللی برچسب فصلی بدون شهر ابهام اضافه میکند. تاریخ، پنجرهی محلی و UTC جدول را برای خواننده‌ای از آمریکای لاتین، آسیا یا آفریقا یکسان روشن میکند.
چرا هفته‌های گذار متفاوت‌اند
در سال 2026 نیویورک 8 مارس و لندن 29 مارس به ساعت تابستانی رفتند. بازگشت‌ها 25 اکتبر در لندن و 1 نوامبر در نیویورک بود. میان این تاریخ‌ها اختلاف معمول وقت محلی دو شهر موقتاً تغییر می‌کرد. تصویری که برای ژانویه درست است، برای چنین هفته‌ای دیگر کافی نیست.
برای مدل ما پنجرههای لندن و نیویورک در ژانویه از 13:00 تا 17:00 UTC و در ژوئیه از 12:00 تا 16:00 UTC هم‌پوشانی دارند. در روزهای کاری 9 تا 27 مارس و 26 تا 30 اکتبر 2026 هم‌پوشانی 12:00–17:00 UTC است: لندن از GMT و نیویورک از EDT استفاده میکند.
سیدنی تقویم خودش را دارد: در نیوساوت‌ولز ساعت تابستانی در سال 2026 در 5 آوریل تمام شد و در 4 اکتبر شروع شد. این تاریخ‌ها را به کل استرالیا تعمیم ندهید: قواعد ایالت‌ها متفاوت‌اند. برای سال بعد تاریخ‌ها را جداگانه به‌روز کنید، حتی اگر ساعتهای معمول بیشتر ماه‌ها همان بمانند.
چگونه UTC را به وقت خودتان تبدیل کنیم
انحراف محلی جاری را اضافه کنید و تاریخ تقویمی را بررسی کنید. رویدادی در 22:00 UTC برای منطقه‌ی UTC+4 در 02:00 روز بعد رخ می‌دهد. خطا در تاریخ ناخوشایندتر از آنچه به نظر می‌رسد است: ممکن است در دفتر خاطرات معامله‌ای «فردا» ظاهر شود، در حالی که در فایل خروجی هنوز به روز قبل تعلق دارد.
برای خواننده‌ای در UTC+7، پنجرهی لندن مدل ما در ژانویه با 15:00–00:00 و در ژوئیه با 14:00–23:00 مطابقت دارد. ساعتهای خانه شاید اصلاً تغییر نکنند، اما گذار بریتانیا باز هم زمان مشاهده را نسبت به عصر شما جابه‌جا میکند. به همین ترتیب برنامهی فصلی منطقه‌ی دیگر وارد روال روزانه‌ی عادی می‌شود.
به همین ترتیب منطقه‌ی ثابت خانگی UTC−5 در ژانویه با وقت نیویورک می‌خواند، اما در ژوئیه نه، چون نیویورک از UTC−4 استفاده میکند. بنابراین بهتر است رویداد را در تقویم به‌صورت Europe/London یا America/New_York ذخیره کنید و نمایش آن را روی تاریخ انتخابی بررسی کنید. این نام‌ها برخلاف تعداد ثابت ساعت، قواعد فصلی را لحاظ می‌کنند.
هم‌پوشانی جلسه‌ها زمینه است، نه سیگنال بالا یا پایین
فعالیت هم‌زمان چند مرکز ممکن است با ماهیتی متفاوت از ساعتهای آرام‌تر حرکت همراه باشد. اما از هم‌پوشانی لندن و نیویورک نمی‌توان جهت شمع بعدی را نتیجه گرفت. در همان پنجره روندها، رنج‌ها، بازگشت‌ها و واکنش‌های تند به اخبار دیده می‌شود.
فعالیت بالا خودبه‌خود به معنای ورود مناسب نیست. قیمت می‌تواند سریع‌تر حرکت کند، ناحیه را قطع کند و پیش از تمام شدن بررسی پارامترهای شما برگردد. برای اختیار معامله‌ی دیجیتال موقعیت قیمت در لحظه‌ی مشخص تسویه اهمیت دارد، نه دامنه‌ی کل ساعت. بزرگ‌ترین حرکت روز لزوماً بهترین نتیجه را برای انقضای انتخابی نمی‌دهد.
اگر زمان جزو استراتژی است، آن را به‌عنوان شرط جداگانه بررسی کنید. ابتدا مشخص کنید یک ساعت ثابت UTC را مقایسه می‌کنید یا بخش یکسانی از روز کاری محلی لندن را. اینها پرسش‌های متفاوتی‌اند. نمی‌توان آن‌ها را زیر عنوان «افتتاح اروپا» یکی کرد و انتظار داشت آمار خودش تعریف نادقیق را اصلاح کند.
پنجرهی مشاهده را در intrade.bar می‌سازیم
یک جلسهی آموزشی دمو را در نوامبر 2026 از 14:00 تا 15:00 UTC در نظر بگیرید. درون هم‌پوشانی پنجرههای انتخابی لندن و نیویورک قرار می‌گیرد. برای کلمبیا 09:00–10:00، برای امارات 18:00–19:00 و برای جاکارتا و ویتنام 21:00–22:00 است. این مثالی از سازمان‌دهی زمان است، نه اعلام بهترین ساعت معامله.
یک جفت‌ارز در دسترس و یک فرضیه‌ی از پیش توصیف‌شده را انتخاب کنید، مثلاً واکنش در ناحیه‌ای که از قبل علامت زده‌اید. نمودار TradingView را در intrade.bar باز کنید، تنظیم زمان و تقویم رویدادها را بررسی کنید. پیش از سیگنال مناسب، در دسترس بودن دارایی، مدت لازم و درصد نمایش‌داده‌شده را بررسی کنید. اگر یکی از پارامترها با برنامه نمی‌خواند، صرف‌نظر را ثبت کنید، نه جایگزین تصادفی.
اگر معامله‌ی مورد بررسی ده دقیقه طول می‌کشد و همهی نتایج باید تا 15:00 معلوم باشند، آخرین ورود مجاز حداکثر 14:50 UTC است. این سطر ساده اما مفید برنامهی معاملاتی است. در intrade.bar بستن زودهنگام وجود ندارد: پایان مشاهده طبق برنامه و لغو قرارداد ناتمام دو اقدام متفاوت‌اند.
پس از جلسه عملیات بسته‌شده را به CSV خروجی بگیرید و زمان را به UTC نگه دارید. در ستونی جداگانه می‌توان پنجرهی محلی، نسخه‌ی فرضیه و دلایل صرف‌نظر را افزود. آمار intrade.bar به مقایسه‌ی داراییها و انقضاها کمک میکند، و دسته‌بندی بر اساس ساعتهای انتخابی و شرایط اضافی را راحت می‌توان جداگانه انجام داد. پس از یک جلسهی موفق به خودتان نتیجه‌گیری وعده ندهید: ابتدا مشاهده‌های قابل‌مقایسه جمع کنید.
اخبار، تعطیلات و وقفه‌ها جداگانه بررسی می‌شوند
تقویم اقتصادی ممکن است زمان دستگاه، UTC یا منطقه‌ی انتخاب‌شده‌ی دستی را نشان دهد. پیش از رویداد تنظیم، تاریخ و نام انتشار را بررسی کنید. اسکرین‌شاتی که در ماه دیگر ذخیره شده جای ثبت جاری را نمی‌گیرد. به‌ویژه در هفته‌هایی که کشورها ساعت را هم‌زمان تغییر نمی‌دهند اشتباه آسان است.
تعطیلی در یک مرکز لزوماً کل بازار ارز را نمی‌بندد. می‌تواند ترکیب شرکتکنندگان و ماهیت فعالیت را تغییر دهد، در حالی که مراکز دیگر کار می‌کنند. برنامهی انتقال بانکی، در دسترس بودن نرخ‌ها و امکان باز کردن قرارداد دیجیتال هم لازم نیست با هم بخوانند. پرسش را مشخص بپرسید: کدام دارایی، کدام محصول و کدام لحظه برایتان مهم است؟
اگر پلتفرم مدت لازم را ارائه نمی‌دهد یا دارایی موقتاً در دسترس نیست، جدول کلی جلسه‌ها این محدودیت را لغو نمی‌کند. معامله را فقط برای حفظ تعداد برنامه‌ریزی‌شده‌ی عملیات به ابزار دیگری منتقل نکنید. در این حالت می‌توان مشاهده را تمام کرد یا بدون باز کردن ادامه داد و دلیل صرف‌نظر را برای تحلیل ذخیره کرد.
Bitcoin و حدهای روزانه با ساعتهای خودشان زندگی می‌کنند
در intrade.bar جفت BTC/USDT شبانهروزی، از جمله آخر هفته‌ها، در دسترس است؛ آخر هفته فقط همین دارایی در دسترس است. نرخ‌های آن از Binance می‌رسد. این به آن معنا نیست که جفتارزها همین برنامه را دارند و جلسهی رمزارز ادامه‌ی لندنی می‌شود. Bitcoin رژیم بازار دیگری دارد که آزمون فرضیه‌ی خودش را می‌طلبد.
مدت هم جداگانه بررسی می‌شود: برای BTC در اسپرینت حداقل مدت پنج دقیقه است. دسترسی شبانهروزی برابر با امکان انتخاب هر انقضا نیست. پیش از عملیات شرایط واقعی در فرم معامله، از جمله درصد، مهم است. راحتی ترمینال مشترک تفاوت داراییها را لغو نمی‌کند.
تقویم جداگانه‌ی دیگر مدیریت ریسک اختیاری intrade.bar است. روز برای حدها ساعت 00:00 به وقت مسکو یا 21:00 UTC شروع می‌شود. این مرز تنظیمات است، نه پایان جلسهی لندن یا نیویورک. اگر حدها را فعال کرده‌اید، این لحظه را در برنامه لحاظ کنید؛ مرز تعیین‌شده فقط از روز بعد قابل تغییر است.
با یک پنجرهی مشاهده‌ی روشن در حساب دمو intrade.bar شروع کنید و آن را همراه با تاریخ و UTC ذخیره کنید. پس از تغییر ساعت‌ها تطابق با وقت محلی را دوباره بررسی کنید و نتایج را بر اساس تعریف یکسان جلسه مقایسه کنید. آن‌گاه برنامه ابزار مفیدی برای سازمان‌دهی معامله می‌شود، نه تصویر دیگری که باید به حرفش اعتماد کرد.
پرسش و پاسخ
چرا جدولهای مختلف Forex ساعتهای متفاوتی نشان میدهند؟
نویسندگان میتوانند مرزهای محلی جلسه، منطقههای زمانی یا رژیمهای فصلی متفاوتی انتخاب کنند. اینجا برای مقایسه از پنجرهی آموزشی 08:00–17:00 هر مرکز استفاده شده؛ برنامهی همهی شرکتکنندگان بازار یا intrade.bar نیست.
آخر هفته در intrade.bar کدام داراییها در دسترساند؟
آخر هفته BTC/USDT در دسترس است که منبع آن Binance است. جفتارزها همراه با Bitcoin به رژیم هفتگی شبانهروزی نمیروند. مدت و درصد در دسترس را در ترمینال بررسی کنید.
معاملههای CSV در intrade.bar را به چه زمانی مقایسه کنیم؟
خروجی از UTC استفاده میکند. زمان اولیه را نگه دارید و جلسهی محلی را در ستونی جداگانه با لحاظ تاریخ و انحراف فصلی بیفزایید. به این ترتیب تغییر ساعت پنجرههای کاری متفاوت را با هم نمیآمیزد.
اولین معامله آموزشی را انجام دهید
حساب دمو بلافاصله پس از ثبت‌نام باز می‌شود
