Múi giờ và DST: lỗi âm thầm làm bot chạy sai giờ mỗi năm hai lần
Có một loại lỗi trong vận hành bot mà bạn không thấy trong log, không thấy trong báo cáo lợi nhuận, và thường chỉ được phát hiện khi bạn ngồi so sánh lệnh thật với tín hiệu mà chiến lược của bạn "lẽ ra" phải vào.
Bot đó vẫn chạy. Nó vẫn mở lệnh. Nó vẫn ghi log đầy đủ. Nhưng nó đang vào lệnh sai một giờ — hoặc bỏ qua cả phiên giao dịch — vì ba đồng hồ trong hệ thống của bạn không còn khớp nhau.
Đây là bài khó viết nhất trong loạt bài về vận hành bot, vì nó ít hấp dẫn. Nhưng nó là bài có khả năng giải thích những kết quả kỳ lạ nhất mà bạn từng thấy: một chiến lược backtest tốt nhưng chạy thật kém; một lệnh đáng ra phải vào lúc mở phiên London lại vào lúc nghỉ; những ngày có kết quả lệch hẳn khỏi mọi ngày khác trong năm.
1. Ba đồng hồ trong một hệ bot
Mọi hệ bot đều có ít nhất ba đồng hồ, và chúng không nhất thiết chỉ cùng một giờ.
Đồng hồ 1 — Giờ máy chủ (VPS). Đây là đồng hồ của hệ điều hành. Nó có múi giờ riêng, và nó có thể được đặt thành UTC, giờ nhà bạn, hoặc bất cứ thứ gì bạn chọn lúc setup.
Đồng hồ 2 — Giờ broker. Đây là đồng hồ mà MT5 dùng khi trả về thời gian nến, thời gian tick, và thời gian mở/đóng lệnh. Đây là đồng hồ quan trọng nhất, vì nó là đồng hồ mà chiến lược của bạn thật sự dựa vào.
Điểm quan trọng: giờ broker không phải giờ máy chủ của bạn. Nó do broker đặt, thường là một trong những chuẩn phổ biến (giờ máy chủ của broker, thường là GMT+2/GMT+3 theo mùa với nhiều broker). Và nhiều broker đổi giờ theo mùa, giống như DST nhưng dịch chuyển theo lịch khác với lịch của bạn.
Đồng hồ 3 — Giờ trong chiến lược của bạn. Đây là đồng hồ bạn đã dùng khi viết và backtest chiến lược. Nếu bạn backtest trên dữ liệu theo giờ broker, thì giờ trong chiến lược là giờ broker. Nếu bạn backtest trên dữ liệu đã quy đổi, thì nó là giờ bạn quy đổi.
Lỗi xảy ra khi ba đồng hồ này không được ghi rõ ở bất cứ đâu. Khi đó, bạn vận hành bằng ký ức và phỏng đoán — và ký ức về múi giờ là thứ tệ nhất để tin, vì nó đúng vào lúc bạn để ý và sai vào lúc bạn không.
Cách kiểm tra nhanh: mở VPS, xem giờ hệ điều hành; mở MT5, xem giờ cảm biến thị trường báo; mở đoạn code của bạn, xem giờ nào được dùng cho các điều kiện. Ba con số đó lệch bao nhiêu? Nếu bạn không trả lời được ngay, hệ thống của bạn đang có một lỗ hổng vận hành cụ thể.
2. Sáu lỗi do giờ, và cách chúng biểu hiện
Điều khiến lỗi múi giờ khó chịu là nó không báo lỗi. Nó biểu hiện thành những hiện tượng có vẻ thuộc về chiến lược, nên bạn thường đi tìm nguyên nhân sai chỗ.
Lỗi 1 — Vào lệnh lệch giờ một tiếng. Đây là lỗi phổ biến nhất. Chiến lược của bạn được viết để vào lệnh "khi mở phiên London", nhưng vì chênh lệch múi giờ, bot thật sự vào lệnh một giờ sau. Hậu quả: bạn vào muộn hơn kế hoạch, ở mức giá tệ hơn. Nếu bạn thấy kết quả chạy thật kém hơn backtest một cách có hệ thống, đây là nghi phạm đầu tiên cần loại trừ.
Điểm hay của lỗi này: nó lệch cùng một hướng, nên nó có dạng một sai số hệ thống chứ không phải nhiễu. Một chiến lược có lợi nhuận kỳ vọng dương mà kết quả thật luôn thấp hơn kế hoạch một khoảng đều nhau là dấu hiệu rõ.
Lỗi 2 — Bỏ qua cả một phiên. Nếu chiến lược của bạn chỉ hoạt động trong một khoảng thời gian cụ thể (ví dụ phiên Á), và đồng hồ bị lệch đủ nhiều, bot có thể không bao giờ thấy khoảng đó. Kết quả: không có lệnh nào — và không có lỗi nào. Đây là kiểu lỗi im lặng nhất, vì nó biểu hiện thành sự im lặng.
Lỗi 3 — Vào lệnh trong giờ không có thanh khoản. Ngược với lỗi 2. Nếu bot nghĩ đang là phiên London trong khi thật ra đang là giữa phiên Á, nó sẽ vào lệnh trong giờ thanh khoản mỏng: spread rộng, trượt giá lớn, và trong trường hợp xấu là cuối tuần.
Đây là lỗi dễ nhận ra khi bạn nhìn danh sách lệnh: có những lệnh vào gần thời điểm đóng/mở thị trường. Hãy kiểm tra những lệnh này trước khi kết luận chiến lược có vấn đề.
Lỗi 4 — Lịch kinh tế lệch so với thực tế. Nếu bot tránh vào lệnh trước 30 phút khi có tin quan trọng, nhưng lịch tin bạn nạp đang theo một múi giờ khác, bot sẽ tránh sai khoảng thời gian. Nguy hiểm hơn: có những lần bot vào lệnh đúng lúc tin ra, đúng lúc spread giãn ra gấp nhiều lần.
Lỗi 5 — Nhật ký không khớp với biểu đồ. Khi bạn đọc log để tìm nguyên nhân, bạn so mốc thời gian trong log với thời gian trên biểu đồ. Nếu log của bạn (do bạn tự viết) và biểu đồ (do broker cung cấp) dùng hai đồng hồ khác nhau, mọi suy luận của bạn lệch đúng khoảng đó. Đây là kiểu lỗi làm bạn mất nhiều giờ nhất, vì nó làm chính công cụ điều tra trở nên sai.
Lỗi 6 — Lỗi chỉ xuất hiện hai lần mỗi năm. Đây là lỗi DST (mục 3). Nó không có triệu chứng suốt nhiều tháng, rồi xuất hiện đúng hai ngày trong năm. Vì bạn không gặp nó thường xuyên, bạn không phát hiện được quy luật — trừ khi bạn ghi lại.
Cách tiếp cận chung: với mọi hiện tượng lạ trong vận hành bot, hãy loại trừ giờ trước khi xem xét chiến lược. Việc loại trừ mất 15 phút và đôi khi giải quyết được vấn đề mà bạn đã mất nhiều ngày để tìm.
3. DST: hai lần mỗi năm, và tại sao lịch không khớp
Giờ tiết kiệm ánh sáng ban ngày (DST) là thứ làm mọi hệ thống múi giờ trở nên phức tạp — nhưng với bot, vấn đề không chỉ là DST.
Vấn đề 1 — Lịch đổi giờ giữa các quốc gia khác nhau. Châu Âu và Mỹ đổi DST vào hai ngày khác nhau, thường lệch nhau vài tuần. Nghĩa là có một khoảng 2–3 tuần mỗi năm mà giờ giữa hai nơi lệch đi một tiếng so với bình thường. Nếu bot của bạn dùng thời gian của một nơi để xác định phiên giao dịch ở một nơi khác, khoảng này là lúc lỗi xuất hiện.
Vấn đề 2 — Broker có lịch riêng. Nhiều broker đổi giờ máy chủ của họ để gần với giờ thị trường New York — nhưng không phải tất cả, và không phải cùng một lịch. Có broker đổi giờ máy chủ, có broker không. Nghĩa là bạn không thể suy ra giờ broker từ quy tắc chung của DST — bạn phải lấy từ broker của bạn.
Vấn đề 3 — Máy chủ VPS cũng có múi giờ. Nếu VPS của bạn đặt theo giờ địa phương và bạn tự động cập nhật DST, giờ hệ điều hành sẽ nhảy một tiếng hai lần mỗi năm. Nếu script của bạn dùng giờ hệ điều hành, nó sẽ nhảy theo — có thể đúng, có thể sai, tùy vào việc bạn có muốn nó nhảy hay không.
Vấn đề 4 — Dữ liệu lịch sử. Đây là vấn đề ảnh hưởng tới backtest: dữ liệu lịch sử của bạn có được điều chỉnh theo DST hay không? Nếu bạn backtest trên dữ liệu theo giờ broker, và giờ broker đã đổi qua các năm, thì "15:00" trong dữ liệu năm ngoái và "15:00" trong dữ liệu năm nay có thể không cùng giờ thật. Với chiến lược nhạy cảm theo giờ, điều này có thể tạo ra lợi nhuận ảo trong backtest.
Vấn đề 4 ít được nói tới nhất và là nguyên nhân của rất nhiều backtest trông đẹp. Nếu chiến lược của bạn phụ thuộc mạnh vào giờ, hãy kiểm tra xem dữ liệu bạn dùng có nhất quán về múi giờ hay không trước khi tin vào kết quả.
Điều cần làm đơn giản nhất: ghi lại hai ngày đổi giờ của broker bạn (thường là hai ngày mỗi năm), và đánh dấu chúng trong lịch vận hành. Hai ngày đó là lúc bạn cần kiểm tra. Chỉ vậy thôi, bạn đã tránh được phần lớn vấn đề của mục này.
4. Bốn nguyên tắc để chuẩn hoá giờ
Không cần giải pháp phức tạp. Bốn nguyên tắc sau là đủ cho hầu hết hệ bot cá nhân.
Nguyên tắc 1 — Chọn một đồng hồ làm chuẩn, và đó là giờ broker. Đây là quyết định quan trọng nhất trong cả bài. Lý do: mọi dữ liệu bạn xử lý đều đến từ broker. Nến, tick, giá, thời gian mở lệnh — tất cả đều theo giờ broker. Nếu bạn chọn một đồng hồ khác làm chuẩn, bạn phải quy đổi ở mọi chỗ — và mỗi chỗ quy đổi là một chỗ có thể sai.
Ngược lại, nếu bạn chọn giờ broker làm chuẩn, bạn không phải quy đổi gì trong logic giao dịch. Bạn chỉ quy đổi một lần ở lớp hiển thị — khi bạn đọc log, khi bạn gửi báo cáo, khi bạn so với lịch tin.
Nguyên tắc 2 — Đặt giờ VPS thành UTC. Đây là thói quen tốt và giúp rất nhiều khi làm việc với nhiều máy. UTC không đổi theo mùa, nên giờ hệ điều hành trở thành một tham chiếu ổn định. Bạn có thể mất vài ngày để quen việc log hệ thống không trùng giờ với giờ bạn sống — nhưng lợi ích là bạn không bao giờ phải tự hỏi "máy này đang đổi DST chưa".
Nguyên tắc 3 — Trong code, dùng giờ broker và ghi rõ nó là giờ broker. Hãy đặt tên biến và comment nói rõ. Một biến tên GioMoPhien là mơ hồ; một biến tên GioMoPhien_TheoGioBroker là rõ ràng — và khi bạn quay lại đọc code sau 8 tháng, sự rõ ràng đó có giá trị thật.
Đây là việc nhỏ nhất nhưng hữu ích nhất trong danh sách: viết rõ đơn vị và múi giờ trong tên và comment. Lỗi múi giờ phần lớn là lỗi giao tiếp giữa người viết code lúc này và người đọc code lúc trước — thường là cùng một người.
Nguyên tắc 4 — Mọi chỗ giao tiếp với bên ngoài hệ thống phải nói rõ múi giờ. Báo cáo bạn gửi, cảnh báo bạn nhận, nhật ký bạn ghi, và file trạng thái bạn chia sẻ — tất cả nên có múi giờ trong tên hoặc trong nội dung. Một thông báo "bot dừng lúc 03:12" là thông tin thiếu; "bot dừng lúc 03:12 giờ broker" là thông tin dùng được.
Nghe có vẻ nhỏ nhặt, nhưng đây là loại chi tiết làm bạn mất hàng giờ trong lúc đang căng thẳng. Trong bảy thứ cần chuẩn bị cho phục hồi sự cố, múi giờ nằm trong nhóm ít được chuẩn bị nhất và mất nhiều thời gian nhất khi cần.
5. Năm bước chuẩn hoá giờ cho hệ bot đang chạy
Áp dụng cho một hệ đang chạy — bạn không cần dừng bot để làm bước 1 đến bước 4.
Bước 1 — Ghi lại ba đồng hồ hiện tại. Mở VPS và ghi giờ hệ điều hành (kèm múi giờ). Mở MT5 và ghi giờ cảm biến thị trường (nến H1 gần nhất). Mở code của bạn và ghi giờ được dùng cho các điều kiện. Viết ba con số vào tài liệu vận hành.
Đây là bước bạn cần làm trước khi nghĩ tới bất cứ thay đổi nào, vì bạn cần biết điểm xuất phát. Trong nhiều trường hợp, việc ghi lại ba con số đã đủ để bạn nhìn thấy một lệch cần xử lý.
Bước 2 — Quyết định giờ chuẩn và ghi nó vào tài liệu. Với hầu hết hệ bot, đó là giờ broker. Ghi vào tài liệu vận hành: "Giờ chuẩn của hệ thống này là giờ broker. Mọi mốc thời gian trong log, báo cáo và nhật ký đều theo giờ broker trừ khi có ghi chú khác."
Câu này nghe nhàm, nhưng nó là câu giải quyết nhiều tranh cãi trong tương lai — kể cả khi "tranh cãi" là giữa bạn của hôm nay và bạn của sáu tháng sau.
Bước 3 — Ghi rõ múi giờ trong mọi mốc thời gian ở lớp hiển thị. Cảnh báo gửi tới điện thoại, báo cáo hằng ngày, file trạng thái — tất cả nên có "giờ broker" ở đâu đó, hoặc một dòng chú thích ở đầu. Nếu bạn muốn hiển thị giờ của mình, hãy hiển thị cả hai.
Việc này quan trọng vì nó ảnh hưởng trực tiếp tới việc bạn ra quyết định khi đang căng thẳng. Khi bạn nhận cảnh báo lúc 2 giờ sáng, việc phải tự quy đổi múi giờ trong đầu là việc bạn không nên phải làm.
Bước 4 — Kiểm tra giờ định kỳ, không chỉ khi có sự cố. Thêm một việc nhỏ vào kiểm tra hằng tuần: xác nhận giờ VPS và giờ broker lệch đúng như bạn đã ghi. Nếu lệch khác, có gì đó đã thay đổi — có thể DST của một bên, có thể ai đó đổi cấu hình.
Đây là kiểm tra cực rẻ: nhìn hai con số và so với tài liệu. Nhưng nó là cách duy nhất để phát hiện lệch giờ trước khi lệch đó ảnh hưởng tới lệnh.
Bước 5 — Đánh dấu hai ngày DST của broker vào lịch vận hành. Mỗi năm hai lần, bạn cần kiểm tra giờ và xác nhận bot vẫn hiểu đúng. Đây cũng là lúc tốt để xem lại log lệnh quanh thời điểm đổi giờ ở năm trước, và ghi lại kết quả vào nhật ký.
Nếu bạn không biết lịch DST của broker, hai cách tìm: (a) tài liệu của broker, hoặc (b) tự xác định bằng cách quan sát nến — chọn một nến H1 vào một giờ trùng khớp, và xem giờ của nó lệch bao nhiêu so với giờ UTC trong hai tuần quanh thời điểm đổi giờ.
6. Kiểm tra trước và sau hai ngày đổi giờ
Đây là danh sách dùng được ngay, cho hai ngày mỗi năm.
Trước ngày đổi giờ (1–2 ngày):
- Xác nhận ngày đổi giờ của broker (không phải của bạn, không phải của VPS)
- Ghi lại giờ broker hiện tại và giờ VPS hiện tại
- Kiểm tra có tin quan trọng nào trong khoảng vài giờ quanh thời điểm đổi giờ không
- Nếu chiến lược của bạn nhạy cảm với giờ, cân nhắc giảm khối lượng hoặc tạm nghỉ trong ngày đó
Trong ngày đổi giờ:
- Sau khi giờ đổi, kiểm tra lại giờ broker và so với ghi chú trước đó
- Kiểm tra bot có vào lệnh đúng khoảng thời gian dự kiến không
- Đọc log tìm những lệnh vào bất thường so với giờ dự kiến
Sau ngày đổi giờ (1–2 ngày):
- So sánh kết quả hai ngày này với những ngày bình thường
- Kiểm tra lịch tin có còn khớp giờ không (nếu bạn nạp lịch từ nguồn ngoài)
- Ghi lại vào nhật ký: ngày đổi giờ, giờ trước và sau, có vấn đề gì không
Việc ghi lại quan trọng hơn bạn nghĩ. Nếu năm nay bạn gặp một lỗi giờ, sang năm bạn sẽ gặp lại đúng lỗi đó — trừ khi bạn có ghi chú. Đây là loại lỗi không tự tiết lộ quy luật, nên chỉ có ghi chép mới biến nó thành thứ học được.
Một lưu ý thực tế: đừng đổi nhiều thứ cùng lúc trong ngày đổi giờ. Nếu bạn cập nhật MT5, đổi cấu hình VPS, và sửa logic EA cùng tuần với ngày đổi giờ, bạn sẽ không biết thứ nào gây ra vấn đề. Hãy để ngày đổi giờ là một biến số duy nhất.
7. Câu hỏi thường gặp
Hỏi: Tôi nên đổi giờ VPS thành UTC hay giữ giờ địa phương? UTC. Giờ địa phương không có lợi ích kỹ thuật nào và thêm một biến số (DST của máy) mà bạn phải theo dõi. UTC cố định, và mọi hệ thống khác đều dễ quy đổi từ UTC.
Hỏi: Tại sao bot tôi chạy đúng nhiều tháng rồi đột nhiên sai giờ? Ba khả năng theo thứ tự phổ biến: (a) DST — của broker hoặc của VPS — vừa đổi; (b) bạn vừa cập nhật hệ điều hành và nó đổi cấu hình múi giờ; (c) bạn vừa đổi broker và broker mới dùng múi giờ khác. Hãy kiểm tra theo thứ tự này.
Hỏi: Backtest của tôi rất tốt nhưng chạy thật kém. Có phải do giờ không? Có thể. Cách kiểm tra nhanh: lấy 20 lệnh thật gần nhất và so giờ vào lệnh với giờ mà chiến lược lẽ ra phải vào. Nếu lệch đều một khoảng, đó là lỗi giờ. Nếu lệch ngẫu nhiên, hãy tìm nguyên nhân khác.
Hỏi: Làm sao biết broker của tôi đổi giờ theo lịch nào? Hai cách. Cách chắc nhất: tài liệu của broker (nhiều broker ghi rõ "server time" và lịch đổi). Cách thực nghiệm: trong hai tuần quanh thời điểm đổi giờ, so giờ nến H1 với giờ UTC, và xem độ lệch thay đổi vào ngày nào. Cách thứ hai đòi hỏi bạn ghi lại, nhưng nó đúng với broker của bạn thay vì đúng theo quy tắc chung.
Hỏi: Có nên quy đổi mọi thứ sang giờ của tôi để dễ đọc không? Không, đừng quy đổi trong logic giao dịch. Quy đổi chỉ ở lớp hiển thị, và ở đó nên hiển thị cả giờ broker lẫn giờ của bạn. Mỗi lần bạn thêm một phép quy đổi vào đường đi của dữ liệu, bạn thêm một chỗ có thể sai.
Cách tự xác định giờ broker bằng một buổi quan sát
Nếu tài liệu broker không nói rõ, hoặc bạn không tin tài liệu, có một cách xác định khá chắc mà không cần công cụ gì.
Bước 1 — chọn một nến có giờ dễ nhận biết. Nến H1 mở đầu tuần là lựa chọn tốt: nó gắn với giờ mở phiên, và giờ mở phiên thì khá cố định theo lịch thị trường. Nến M15 quanh thời điểm mở/đóng phiên cũng dùng được.
Bước 2 — ghi giờ của nến theo giờ MT5. Đặt con trỏ lên nến và đọc thời gian. Đây là giờ broker.
Bước 3 — ghi giờ thật của thời điểm đó bằng một nguồn bên ngoài. Dùng giờ UTC từ một nguồn độc lập (đồng hồ hệ thống đặt UTC, hoặc một trang thời gian). Bạn cần biết thời điểm thật để so.
Bước 4 — tính độ lệch. Chênh lệch giữa hai con số là độ lệch giữa giờ broker và UTC.
Bước 5 — lặp lại việc này hai tuần quanh thời điểm đổi giờ. Bạn sẽ thấy độ lệch đổi giá trị (thường từ +2 sang +3, hoặc ngược lại) vào một ngày cụ thể. Ngày đó chính là ngày broker đổi giờ.
Cách này không cho bạn toàn bộ quy tắc, nhưng nó cho bạn thứ bạn cần: độ lệch hiện tại, và ngày đổi giờ năm nay để bạn ghi vào lịch. Hai thông tin đó là đủ cho vận hành.
Một lưu ý: hãy ghi việc xác định này vào nhật ký vận hành, kèm giá trị bạn đo được và ngày bạn đo. Sang năm, khi độ lệch đổi, bạn sẽ muốn biết nó từng bằng bao nhiêu — chứ không phải đo lại từ đầu.
Giờ ảnh hưởng tới bảy thứ cần chuẩn bị khi phục hồi sự cố
Múi giờ không chỉ ảnh hưởng tới logic giao dịch. Nó ảnh hưởng tới cả khả năng phục hồi, và đây là chỗ nó gây hậu quả rõ nhất.
1. Nhật ký sự cố. Nếu bạn ghi "bot dừng lúc 3 giờ" mà không nói giờ nào, thông tin đó gần như vô dụng khi so với log của broker hay của nhà cung cấp VPS — những nơi dùng đồng hồ khác.
2. Thời điểm quyết định. Khi có sự cố, bạn cần trả lời "còn bao lâu nữa tới phiên London" hoặc "còn bao lâu nữa mới có tin". Nếu bạn phải tự quy đổi trong đầu, bạn sẽ mất thêm phút — đúng lúc bạn cần phút đó nhất.
3. Bản sao lưu theo giờ. Nếu bạn sao lưu theo giờ hệ điều hành, và giờ đó nhảy do DST, bạn có thể có hai bản sao lưu lệch nhau một tiếng mà không biết. Không nguy hiểm, nhưng làm việc chọn bản sao để khôi phục trở nên khó khăn.
4. Lịch sự cố năm trước. Sau một năm, mọi mốc thời gian bạn ghi đều có thể nằm ở múi giờ khác (do DST). Không ghi rõ múi giờ nghĩa là lịch sử của bạn không so sánh được theo thời gian.
5. Báo cáo cho người khác. Nếu bạn làm việc với người khác, hoặc với nhà cung cấp VPS, một mốc thời gian thiếu múi giờ làm cuộc trao đổi chậm lại.
6. Tài liệu khôi phục. Kịch bản dựng lại gồm các bước như "chờ đến khi thị trường đóng rồi sao chép dữ liệu" — câu đó cần giờ nào để biết "thị trường đóng" là mấy giờ?
7. Kiểm tra sau khi khôi phục. Bước xác nhận cuối cùng thường là "chờ tới giờ mở phiên và kiểm tra bot vào lệnh". Nếu bạn không biết giờ broker, bạn không biết mình đang chờ tới khi nào.
Điểm chung của bảy thứ này: chúng đều xuất hiện khi bạn đang căng thẳng. Đó là lý do việc chuẩn hoá múi giờ không phải việc học thuật, mà là việc giảm ma sát cho những giờ phút tệ nhất.
8. Checklist và tóm lại
Làm ngay (30 phút):
- [ ] Ghi lại ba đồng hồ: giờ VPS, giờ broker, giờ dùng trong code
- [ ] Chọn giờ broker làm giờ chuẩn và ghi rõ vào tài liệu vận hành
- [ ] Đặt giờ VPS về UTC
- [ ] Thêm dòng "giờ broker" vào cảnh báo và báo cáo hiện có
Làm trong tháng:
- [ ] Ghi rõ múi giờ trong tên biến và comment ở những chỗ liên quan tới thời gian
- [ ] Thêm việc kiểm tra lệch giờ vào danh sách kiểm tra hằng tuần
- [ ] Tìm và ghi lại lịch đổi giờ của broker bạn
- [ ] Đánh dấu hai ngày đổi giờ vào lịch vận hành
- [ ] Kiểm tra dữ liệu lịch sử dùng cho backtest có nhất quán múi giờ không
Với mọi hiện tượng lạ trong vận hành:
- [ ] Loại trừ giờ trước khi nghi ngờ chiến lược
Bốn nguyên tắc để nhớ:
- Giờ broker là giờ chuẩn — vì mọi dữ liệu bạn xử lý đều đến từ broker.
- VPS đặt UTC — cố định, không có DST, dễ quy đổi.
- Mọi mốc thời gian giao tiếp ra ngoài phải nói rõ múi giờ. Một thông báo thiếu múi giờ là một thông báo có thể gây hiểu sai.
- Hai ngày đổi giờ mỗi năm là hai ngày phải kiểm tra. Đánh dấu chúng trước, đừng dựa vào việc nhớ.
Và nếu bạn chỉ làm được một việc sau khi đọc bài này: hãy mở VPS và MT5, ghi lại hai giờ đó ngay bây giờ. Chỉ mất một phút, và nó là bước đầu tiên để biết hệ thống của bạn có đang lệch giờ hay không. Lỗi múi giờ là loại lỗi duy nhất trong vận hành bot mà càng phát hiện muộn càng tốn nhiều — vì suốt thời gian đó, bot vẫn đang giao dịch bằng tiền thật, chỉ là không đúng như bạn thiết kế.