Я совсем потерялся - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вы недоумеваете по поводу того, чему более десяти лет? Вы хотя бы слышали о Y2K? Если нет, то вы просто недоумеваете, почему даты хранятся только с двумя цифрами в году, так что после 1999 года был год 1900 или 19100.
Вы, вероятно, недоумеваете, почему IP-адреса ограничены 4,2 миллиардами в мире с 7 миллиардами людей. Кто-то принял это решение в DARPA, когда пытался соединить существующие (десятки) мейнфреймов в стране. Теперь мы переходим на IPv6 с IPv4.
Смиритесь с собой. Это не Бергер Кинг, вы не получите все по-своему. Кто-то принял решение, которое в то время казалось разумным, а теперь таковым не является. Смиритесь с этим.
ydrol, ради всего святого, пожалуйста, скажите мне - если вы знаете - можно ли использовать static_cast в mql4! Это то же самое, что и в C++? На этой странице https://docs.mql4.com/basis/types/casting об этом не упоминается, я не могу найти это на форумах, я не могу найти это нигде. Я постоянно сталкиваюсь с ситуациями в кодинге, не только при преобразовании datetime в long, но и datetime в double, где это неизбежно, поэтому я хочу сделать это правильно. В частности, программа определяет, в какой части недели находится образец, и соответствующим образом подчеркивает это в своих вычислениях - но время по модулю количества секунд в неделе все еще является переменной типа datetime, и если я не могу преобразовать ее во что-то другое, она так и застрянет. Но мне нужно выполнить математическую функцию над ней, и чтобы в конце она была двойкой, понимаете. Если вы не знаете, то не беспокойтесь, но если знаете, пожалуйста, скажите мне, как я должен правильно приводить типы в такой ситуации.
В документации есть целый раздел о типах данных и типизации. Вы нажимаете F1 во время работы с редактором?
Это часовой пояс сервера вашего брокера. НАВСЕГДА. Любое время, которое вы получаете от mt4 - это часовой пояс вашего сервера. (За исключением TimeLocal() и нового TimeGMT в mt5).
Вы недоумеваете по поводу того, чему более десяти лет? Вы хотя бы слышали о Y2K? Если нет, то вы просто недоумеваете, почему даты хранятся только с двумя цифрами в году, так что после 1999 года был год 1900 или 19100.
Вы, вероятно, недоумеваете, почему IP-адреса ограничены 4,2 миллиардами в мире с 7 миллиардами людей. Кто-то принял это решение в DARPA, когда пытался соединить существующие (десятки) мейнфреймов в стране. Теперь мы переходим на IPv6 с IPv4.
Смиритесь с собой. Это не Бергер Кинг, вы не получите все по-своему. Кто-то принял решение, которое в то время казалось разумным, а теперь таковым не является. Смиритесь с этим.
Это часовой пояс сервера вашего брокера. ПЕРИОД. Любая дататайм, которую вы получаете из mt4, является часовым поясом вашего сервера. (Исключая TimeLocal() и новый mt5 TimeGMT.
Я снова вспомнил об этом только потому, что в настоящее время переношу свои функции TimeZone/Session в аккуратный класс mql4++!
WHRoeder: Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.
Я справляюсь с этим, но все еще недоумеваю, зачем мне это вообще нужно! Лучшие практики по управлению информацией о часовых поясах существуют уже давно. С 1988 года. Например, для ISO 8601
Часовые пояса в ISO 8601 представлены как местное время (с неуказанным местоположением), как UTC или как смещение от UTC.
Если в представлении времени нет информации о связи с UTC, предполагается, что время указано по местному времени. Хотя при общении в одном часовом поясе можно считать, что время местное, оно неоднозначно при общении в разных часовых поясах. Обычно предпочтительнее указывать часовой пояс (обозначение зоны), используя обозначения стандарта".
Подчеркнутый бит известен в ИТ уже около 30 лет, если не больше. Формат времени MQL является производным от UnixTime (они не вырвали магическую дату 1/1/1970 из воздуха), поэтому они должны были знать об этом уже сейчас.
Опять же в 1988 году POSIX ратифицировал UnixTime.
"Комитет POSIX был поколеблен аргументами против усложнения библиотечных функций, и твердо определил время Unix простым способом в терминах элементов времени UTC" .[Мое выделение].
Системные архитекторы или разработчики, проектирующие клиент-серверные системы 10 лет назад (что не так уж и давно), которые обмениваются критичной по времени информацией, должны были иметь достаточно информации, чтобы предвидеть/избежать нынешней неразберихи с часовыми поясами. Трейдеры в одном часовом поясе получают данные в другом часовом поясе, которые они иногда хотят интерпретировать в другом часовом поясе (например, NY). Единственными оправданиями являются:
- незнание
- низкий приоритет (путаница в TZ выгодна брокерам, а не трейдерам?).
- какое-то техническое соображение/ограничение/требование, которое не очевидно для нас со стороны. Может быть, рисование графиков или что-то в этом роде? Хотя не так уж сложно добавить/вычесть известное смещение?
Все вышеперечисленное озадачивает меня, как я уже говорил. Мне кажется, что не нужно писать код для расчета времени по Гринвичу во время бэктестинга! Но TimeGMT() и TimeLocal() неправильно смоделированы (они оба установлены на неспецифический TZ, полученный из исторических данных), поэтому нам нужно написать собственные функции часовых поясов, чтобы точно рассчитать UTC и, таким образом, время начала и окончания сессии во время бэктестинга.
PS Ирония по поводу того, что WHRoeder сказал мне "взять себя в руки", не пропала :)