Я совсем потерялся - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Часовой пояс для datetime (секунды после 1970 года) основан на UTC. Так же, как и время Unix. Это UnixTime - 64-битное unix-время.
datetime - datetime = long (продолжительность в секундах)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(another date)
Пожалуйста, не кормите тролля.
Когда вы отвечаете, вы даете троллю власть. Когда вы игнорируете тролля, он голодает, требуя внимания, и в конце концов умирает.
Я считаю, что вы внесли отличный вклад. Ваши сообщения лаконичны и хорошо проработаны, и вы получаете множество резолюций "спасибо" за ваши усилия.
Да, я думаю, вы сделали все, что могли для этого парня.
Как указать время даты в GMT?
ой, забыл, что mql4 использует сломанную концепцию времени. Я допускаю риторический вопрос :-) часовой пояс зависит от того, откуда он пришел. отсюда все проблемы, так как есть несколько источников брокер, компьютер, бэктестинг бла бла бла.
Я боялся, что правила продвижения типов данных будут работать именно так. Итак:
datetime - datetime = long (длительность в секундах)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(другая дата)
Но если я скажу X=Y-Z, или (Y-Z)/60, или что-то вроде этого, где X уже объявлен как long или int, а Y и Z - это времена данных, это очень, очень плохо? И если да, то статический_каст все исправит?
Raptoruk, это не зависит от часового пояса. Конечно, разница между 14:00 и 15:00 составляет 3600 в любом часовом поясе. Но что, если я знаю, что торговля прекращается в 5 часов вечера по восточному времени в пятницу, но я не знаю, в каком часовом поясе находится время 0 (полночь 1 января 1970 года)? Тогда у нас возникает проблема, не так ли? Итак, 1 января 1970 года был четверг. Если время 0 находится в GMT, то торговля прекращается через 46 часов после этого, или 165600 по модулю 604800. Другими словами, если в неделе 604800 секунд, я использую арифметическую операцию X%604800 для остатка при делении на 604800, и торговля останавливается на 165600. Однако, если брокер находится в 2 часовых поясах к востоку от этого, и их хлам имеет временную метку на 7200 выше, то торговля останавливается, когда time%604800 будет 172800, а не 165600.
Похоже, что существует неопределенность в отношении сообщаемых временных индексов. Думаю, мне нужно, чтобы мой код вычислил время по модулю 604800, в которое торговля начинается и останавливается, просто чтобы быть уверенным. Я думаю, что просматриваю что-то вроде iTime('USDJPY',60,X) и нахожу промежутки в 48 часов. Я могу полагаться на то, что iTime - это время "открытия", НАЧАЛО часа, верно? Другими словами, торговля останавливается через 1 час после последнего показателя времени перед двухдневным гэпом, и возобновляется точно в начале первого после гэпа, а затем добавление кратных 604800 просто меняет неделю. Хотя здесь возникнут дополнительные сложности, например, что если на какой-то неделе будет пропущен последний час или пропущен первый час. Может быть, использовать iTime('USDJPY',1,X), чтобы я отклонялся максимум на несколько минут.
О, ух ты, много постов, которые так быстро закончились. Просто чтобы все остальные знали, я думаю, что raptoruk в конце концов в порядке, но куча инвектив не приветствуется, так что если вы не ydrol или raptoruk или кто-то новый с чем-то новым, чтобы сказать, просто перестаньте писать, я не тролль, потому что меня не волнуют ваши эмоциональные состояния так или иначе, и если у вас есть что-то еще, чтобы бросить вокруг, знайте, что это падает на глухие уши.
Я боялся, что правила продвижения типов данных будут работать именно так. Итак:
datetime - datetime = long (длительность в секундах)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(другая дата)
Но если я скажу X=Y-Z, или (Y-Z)/60, или что-то вроде этого, где X уже объявлен как long или int, а Y и Z - это время даты, будет ли это очень, очень плохо? И если да, то статический_каст все исправит?
Raptoruk, это не зависит от часового пояса.
Но что, если я знаю, что торговля прекращается в 5 часов вечера по восточному времени в пятницу, но я не знаю, в каком часовом поясе находится время 0 (полночь 1 января 1970 года)? Тогда у нас возникает проблема, не так ли!
Я боялся, что правила продвижения типов данных будут работать именно так. Итак:
datetime - datetime = long (длительность в секундах)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(другая дата)
Но если я скажу X=Y-Z, или (Y-Z)/60, или что-то вроде этого, где X уже объявлен как long или int, а Y и Z - периоды времени, будет ли это очень, очень плохо? И если да, то статический_каст все исправит?
Это не "правила продвижения", просто я рассуждаю здраво (я надеюсь!). Как правило, я бы сам сделал вышеупомянутые типы.
Если результатом моих вычислений все еще является число, которое представляет собой секунды с 1/1/1970 (независимо от часового пояса или его отсутствия), то я бы сохранил его как datetime.
В противном случае все остальное (длительность, минуты с 1/1/1970, что угодно) я , вероятно, сохраню как long. (Иногда int, особенно для типичных длительностей и т.д.).
Сказав это, я недоумеваю, как разработчики MQL4 пришли к тому, чтобы не вводить UTC для всех дат и не заставлять всех брокеров посылать данные UTC, а просто заставить клиента интерпретировать их в локальном времени, потому что их текущий подход неоправданно усложняет все последующее.
Это усложняет вычисление времени по Гринвичу и времени открытия/закрытия сессии во время бэктестинга, если вы хотите сделать это правильно для всех источников тиковых данных.
(Например, Alpari имеет несколько часовых поясов в своих исторических данных, так что вы должны быть осторожны с источниками данных при бэктестинге).
PS Отредактировал свой предыдущий фальш :)
Идрол, ради всего святого, пожалуйста, скажите мне - если вы знаете - можно ли использовать static_cast в mql4! Это то же самое, что и в C++? На этой странице https://docs.mql4.com/basis/types/casting об этом не упоминается, я не могу найти это на форумах, я не могу найти это нигде. Я постоянно сталкиваюсь с ситуациями в кодинге, не только при преобразовании datetime в long, но и datetime в double, где это неизбежно, поэтому я хочу сделать это правильно. В частности, программа определяет, в какой части недели находится образец, и соответствующим образом подчеркивает это в своих вычислениях - но время по модулю количества секунд в неделе все еще является переменной типа datetime, и если я не могу преобразовать ее во что-то другое, она так и застрянет. Но мне нужно выполнить математическую функцию над ней, и чтобы в конце она была двойкой, понимаете. Если вы не знаете, то не беспокойтесь, но если знаете, пожалуйста, скажите мне, как я должен правильно приводить переменные в такой ситуации.
raptoruk, "Нет ... ну может вы и знаете, а я нет, так что нет, мы не знаем". Это абсолютная проблема. Не для меня, не для вас, не для нас, а для обоснованности вашего предыдущего заявления о том, что это не зависит от часового пояса. Потому что не имеет значения, в каком часовом поясе находится ваш брокер, торговля на Форекс не следует за часами вашего брокера. В пятницу и воскресенье это 5 вечера по восточному времени. 10 вечера по Гринвичу. А как же переход на летнее/стандартное время! А как же это! Некоторые страны не прибавляют час или вычитают его, или делают это в другой день, так что в итоге вы можете получить код, который на час отличается в течение части года, если нет хорошего способа сделать это. Я еще не выбрал брокера. Тот, которого я пробую, работает по GMT+2, но сейчас я думаю, что они мне не нравятся, судя по их демо-счету. И если я попробую на реальном, возможно, я захочу использовать другого брокера. Поэтому я не хочу, чтобы часовой пояс брокера был жестко закодирован в программе, если это легко сделать. Не будьте снова как тот парень, пытающийся превратить все в возможность бросить оскорбление вместо того, чтобы принять вопрос за чистую монету.