Transaq
СБО "Transaq" => TRANSAQ Connector => Topic started by: Mike+ on Декабря 03, 2023, 08:57:40 pm
-
Добрый вечер.
Обнаружил, что буквально в последний день-два-три в ответе <candles> на запрос gethistorydata время свечей не UTC, а UTC-3:
callback: [<candles secid="24163" board="MCT" seccode="ARQT" period="2" status="1">
<candle date="01.12.2023 17:10:00" open="1.94" close="1.94" high="1.95" low="1.94" volume="12868"/>
<candle date="01.12.2023 17:15:00" open="1.94" close="1.94" high="1.95" low="1.94" volume="14151"/>
<candle date="01.12.2023 17:20:00" open="1.95" close="1.95" high="1.95" low="1.94" volume="48493"/>
<candle date="01.12.2023 17:25:00" open="1.94" close="1.94" high="1.95" low="1.94" volume="15663"/>
<candle date="01.12.2023 17:30:00" open="1.94" close="1.94" high="1.96" low="1.94" volume="95167"/>
<candle date="01.12.2023 17:35:00" open="1.95" close="1.94" high="1.95" low="1.94" volume="18406"/>
<candle date="01.12.2023 17:40:00" open="1.94" close="1.94" high="1.96" low="1.94" volume="107345"/>
<candle date="01.12.2023 17:45:00" open="1.94" close="1.94" high="1.96" low="1.94" volume="88519"/>
<candle date="01.12.2023 17:50:00" open="1.94" close="1.95" high="1.96" low="1.94" volume="74396"/>
<candle date="01.12.2023 17:55:00" open="1.95" close="2.0" high="2.0" low="1.95" volume="138625"/>
</candles>]
В команде connect явно задаю параметр utc_time = true, а согласно описанию, TC должно выдавать мне свечи с timezone = UTC. Если посмотреть на последнюю свечу "01.12.2023 17:55:00", то возвращаемое время в UTC должно быть "01.12.2023 20:55:00", что в переводе на МСК будет "01.12.2023 23:55:00". В данный момент конвертация в МСК выполняется неверно: "01.12.2023 20:55:00".
Причем терминал Transaq выдает это же неверное московское время, а веб-терминал Finam -- верное.
Понимаю, что косяк скорее всего не в TransaqConnector, который является клиентом БД Transaq, а в самом функционале Transaq.
На той неделе timezone в свечах был верный. Что делать? Косяк ведь, не?
Спасибо.
-
Провел эксперимент и запросил свечи на российский ВТБ:
callback: [<candles secid="2348" board="TQBR" seccode="VTBR" period="2" status="1">
<candle date="01.12.2023 20:00:00" open="0.02358" close="0.02358" high="0.02358" low="0.023565" volume="3191"/>
<candle date="01.12.2023 20:05:00" open="0.02358" close="0.023565" high="0.02359" low="0.023565" volume="3038"/>
<candle date="01.12.2023 20:10:00" open="0.023585" close="0.02358" high="0.023585" low="0.023565" volume="3062"/>
<candle date="01.12.2023 20:15:00" open="0.023585" close="0.02357" high="0.023585" low="0.02356" volume="6617"/>
<candle date="01.12.2023 20:20:00" open="0.023565" close="0.02357" high="0.02358" low="0.023525" volume="48092"/>
<candle date="01.12.2023 20:25:00" open="0.02357" close="0.02354" high="0.0236" low="0.023525" volume="28489"/>
<candle date="01.12.2023 20:30:00" open="0.023535" close="0.023525" high="0.02356" low="0.02352" volume="34166"/>
<candle date="01.12.2023 20:35:00" open="0.023525" close="0.02353" high="0.023585" low="0.02352" volume="35073"/>
<candle date="01.12.2023 20:40:00" open="0.023545" close="0.023525" high="0.02358" low="0.023525" volume="29019"/>
<candle date="01.12.2023 20:45:00" open="0.02353" close="0.02361" high="0.02361" low="0.023525" volume="74389"/>
</candles>]
Тут свечи вернулись с верным timezone = UTC. Последняя для 1 декабря свеча "01.12.2023 20:45:00", что в МСК будет "01.12.2023 23:45:00".
Получается, что для board TQBR timezone верный, а для board MCT -- нет. Хотя акция ARQT (board MCT) закончила основную сессию в 23-55.
-
Сегодня свечи для MCT стали с верной UTC-шной таймзоной приходить. Видимо, исправили.
-
Началось опять: время в свечах не UTC.
callback: [<candles secid="10766" board="MCT" seccode="NVDA" period="2" status="1">
<candle date="08.12.2023 17:10:00" open="475.06" close="475.1" high="475.17" low="474.47" volume="212112"/>
<candle date="08.12.2023 17:15:00" open="475.09" close="475.06" high="475.44" low="474.98" volume="131486"/>
<candle date="08.12.2023 17:20:00" open="475.06" close="474.95" high="475.17" low="474.65" volume="185917"/>
<candle date="08.12.2023 17:25:00" open="474.95" close="475.13" high="475.39" low="474.74" volume="198385"/>
<candle date="08.12.2023 17:30:00" open="475.1" close="475.03" high="475.39" low="474.92" volume="182145"/>
<candle date="08.12.2023 17:35:00" open="475.04" close="475.14" high="475.28" low="474.83" volume="210119"/>
<candle date="08.12.2023 17:40:00" open="475.19" close="474.81" high="475.39" low="474.77" volume="244857"/>
<candle date="08.12.2023 17:45:00" open="474.79" close="474.77" high="475.01" low="474.57" volume="302646"/>
<candle date="08.12.2023 17:50:00" open="474.69" close="474.9" high="475.16" low="474.66" volume="422455"/>
<candle date="08.12.2023 17:55:00" open="474.92" close="475.08" high="475.21" low="474.92" volume="486331"/>
</candles>]
Свеча "08.12.2023 17:55:00" -- это последняя свеча NVDA 8 декабря. В данных должно передаваться UTC = "08.12.2023 20:55:00".
Как и в прошлый раз случилось при запросе свечей на выходных днях и исправилось с наступлением понедельника.
Кто-нибудь из поддержки может это объяснить?? Косяк серьезный. Такое поведение не соответствует заявленному в инструкции на TransaqConnector.
-
Ребята-разработчики, вы где? :)
-
Вы Финаму в поддержку сообщали? Настройками таймзоны инструментов заведует Брокер.
-
Вы Финаму в поддержку сообщали? Настройками таймзоны инструментов заведует Брокер.
Не сообщал. Просто я не совсем ясно представляю цепочку информационного взаимодействия.
Есть какие-то Transaq серверы, поэтому я решил, что цепочка выглядит примерно так:
Клиент --- TransaqConnector / Transaq --- Transaq сервер --- Брокер
Решил, что проблема может быть где-то на участке "TransaqConnector / Transaq --- Transaq сервер".
Брокер меня пошлёт, сославшись на то, что TransaqConnector -- это вообще прикладное ПО, к Брокеру отношения не имеющее. Они спросят меня: "в FINAM WebTerminal время отображается корректно?", я отвечу, что "да". После этого они резонно отправят меня куда подальше. Мои договорные отношения с Брокером -- брокерский счет и возможность проведения операций средствами, которые он мне предоставляет. За TransaqConnector они не отвечают. А их средства отображают информацию корректно. У вас же другие договорные отношения с кем-то, от кого вы получаете биржевые данные: от Финама напрямую или через промежуточное лицо (какой-нибудь оператор БД Transaq). Выставить рекламацию можно только в рамках обязательств по конкретному договору обслуживания. Ну не буду же я писать в Финам "Ребята, вы там похоже намудрили с таймзоной при запросе биржевых данных на выходных, которые вы отправляете то ли оператору серверов Transaq, то ли разработчикам TransaqConnector, то ли еще кому-то. Разберитесь". Они ответят мне: "Мальчик, ты кто такой? В рамках договора брокерского обслуживания мы тебе данные своими средствами корректно даем? Корректно. Вот и иди гуляй. Разбирайся с тем, у кого ты берешь данные на стороне".
Я, например, ожидал от Вас, что Вы подтвердите или опровергните поступление от Брокера свечей с разной таймзоной при запросе данных на выходных и в будние. Если к вам информация приходит уже с другой таймзоной -- это одно, если зона по каким-то причинам меняется у вас -- уже другое. В последнем случае -- это ваш баг. В первом случае требуется корректировка инструкции к TransaqConnector, где будет написано, что, например, на выходных таймзона в свечах не равна UTC, несмотря на то, что принудительно стоит флаг utc_time = true в команде connect. На пока на данный момент в инструкции указано, что при установке utc_time = true в определенном перечне ответов от TransaqConnector'а (включая candles) время указано в UTC, что на сегодня не соответствует действительности.
Моя цель -- не ругаться. Просто такое непредсказуемое поведение TC плохо сказывается на доверии к ПО, поскольку получение исторических свечей -- важное средство для получения общей картины по инструментам (котировки, индикаторы, итд). Ведь для чего нужен TransaqConnector: для использования в торговых роботах и скринерах, а для этого получаемая информация должна быть корректной и соответствовать официальной инструкции. Ведь люди пользуются вашим ПО по вашей же инструкцией к нему. Поэтому и ожидается что-то вроде: "да, баг у нас, исправим" или "мы ни при делах, передаем без изменений то, что приходит от Брокера, но инструкцию поправим, чтобы люди учитывали этот нюанс".
-
Здравствуйте.
> Брокер меня пошлёт, сославшись на то, что TransaqConnector -- это вообще прикладное ПО, к Брокеру отношения не имеющее.
Ничего подобного. Финам официально предлагает Коннектор как средство доступа: см. https://www.finam.ru/howtotrade/soft/tconnector/ Какие при этом он берет на себя обязательства - определяется вашим с ним договором, но скорее всего - достаточные.
> У вас же другие договорные отношения с кем-то, от кого вы получаете биржевые данные: от Финама напрямую или через промежуточное лицо (какой-нибудь оператор БД Transaq).
Наши договорные отношения с Финамом не дают нам прав доступа ни к биржевым, ни к клиентским данным. Мы разработчики системы, ее эксплуатацией мы не занимаемся.
> Ну не буду же я писать в Финам "Ребята, вы там похоже намудрили с таймзоной при запросе биржевых данных...
Да, не стОит. Лучше написать то, что вы наблюдаете, а выводы оставить им.
Мы благодарны вам за сообщение о проблеме и стараемся максимально быстро исправлять ошибки нашего софта. Но у нас для этого будет достаточно информации только тогда, когда техподдержка Финама озаботится вашей проблемой.
-
OK, попробую написать в их тех.поддержку
-
Ничего подобного. Финам официально предлагает Коннектор как средство доступа: см. https://www.finam.ru/howtotrade/soft/tconnector/ Какие при этом он берет на себя обязательства - определяется вашим с ним договором, но скорее всего - достаточные.
Наши договорные отношения с Финамом не дают нам прав доступа ни к биржевым, ни к клиентским данным. Мы разработчики системы, ее эксплуатацией мы не занимаемся.
Мы благодарны вам за сообщение о проблеме и стараемся максимально быстро исправлять ошибки нашего софта. Но у нас для этого будет достаточно информации только тогда, когда техподдержка Финама озаботится вашей проблемой.
---------------------------------------
ОБратился в техническую поддержку Финама, вот переписка:
Я: Первый касается биржевых данных, получаемых мной через TransaqConnector. На форуме Connector'а сказали, чтобы я обращался в тех.поддержку Финама.
Я: Там технический вопрос в неверности временной зоны для получаемых исторических свечей. Можно ли отправить суть вопроса на e-mail почту поддержки? И вообще примут ли мой вопрос, касающийся именно TransaqConnector?
Оператор: Мы можем лишь предоставить логин и пароль для работы через транзак коннектор
Оператор: По работе самого приложения консультацию дать не можем
Я: Т.е. Финам не может оказать мне помощь, касающуюся работы с TransaqConnector? Обращаться нужно к разработчикам TransaqConnector?
Оператор: Да верно, так как это сторонее приложение
---------------------------------------
Произошло ровно то, о чем я и писал. То, что TransaqConnector официально предлагается к использованию Финамом, совершенно не означает, что он за него отвечает. Все, что дает Финам -- это токены для доступа к биржевому счету клиента, по которым клиент может получить доступ к БС через сторонние программы. Стандартная практика..
>> Наши договорные отношения с Финамом не дают нам прав доступа ни к биржевым, ни к клиентским данным.
TransaqConnector физически имеет доступ к биржевым данным и передает их клиенту. Потому что в противном случае, пользователи TransaqConnector не смогли бы запрашивать и получать исторические свечи, используя TC. Ваше ПО ведь берёт откуда-то эти данные. Вы в инструкции пишете, что: при utc_time = true время в свечах будет UTC. При запросах в выходные дни получаемые данные не соответствуют тому, что декларируется. Возникает вопрос: у КОГО вы берете эти данные и на каком этапе они "ломаются", то ли у источника, то ли у вас. Я готов писать тому, кто будет меня слушать. Финам слушать меня не захотел. Поэтому я обращаюсь за помощью к разработчикам.
Что мне делать, когда поведение вашего ПО в определенных условиях не соответствует заявленному? Логично же, что разработчик ПО должен подтвердить баг или опровергнуть, дать пояснения тому, кто задает вопрос. А при действительном наличии бага -- исправить его. Инструкцию к TransaqConnector писали вы, а не Финам. Значит разработчик, писавший инструкцию, ясно понимает что он получает от источника биржевых данных, конвертирует эти данные (опционально) и передает клиенту.
-
Логи коннектора на момент ошибки сохранились? xdf и ts-логи особенно интересуют. Если да - пришлите пожалуйста на support@transaq.ru
Хорошо бы посмотреть логи за выходной, когда произошла ошибка и в понедельник, когда все нормализовалось.
-
Логи коннектора на момент ошибки сохранились? xdf и ts-логи особенно интересуют. Если да - пришлите пожалуйста на support@transaq.ru
Хорошо бы посмотреть логи за выходной, когда произошла ошибка и в понедельник, когда все нормализовалось.
Спасибо, Сергей. Логи вышлю. Я как раз сегодня хотел проверить до полуночи и после. Сейчас (пятница) таймзона нормальная и в ts-логе вроде ничего подозрительного. Как наступит суббота, попробую еще раз. Если баг опять проявится -- сразу же вышлю логи "здорового человека" и "алкоголика" :)
-
В пятницу в 23:58 таймзона была корректная. И даже при наступлении субботы в 00:30 тоже все было корректно. Когда проверил в субботу в 13:13, то косяк уже был, таймзона в свечах стала UTC-3.
Логи выслал.
P.S. На всякий случай напомню, что баг есть только для инструментов MCT, для board TQBR (российских) этого бага нет: все свечи приходят строго в UTC.
-
Ради эксперимента в команде connect изменил параметр utc_time на "false" и зона стала UTC в свечах, снятых в субботу. Ставлю обратно utc_time = "true" -- опять косяк, зона съезжает на 3 часа назад...
А DLL-ка получает от источника уже разложенное по таймзоне время или time_t (секунды с Эпохи)? Если time_t, то может вместо календарного (или дополнительно к календарному) добавить в свечи тэг с величиной time_t? Это бы решило проблему)) Те, кто хочет читать календарное, -- берет в расчет календарное, а кто-то будет брать секунды с Эпохи и сам переводить в календарное по местной таймзоне..
-
Ребята, по посяку с таймзоной не разбирались?
-
Исправлено в новой версии сервера:
<server_status sys_ver="640" build="5" server_tz="Russian Standard Time" id="0" connected="false"/>
Нужно ждать когда Финам обновится до этой версии.
-
Исправлено в новой версии сервера:
<server_status sys_ver="640" build="5" server_tz="Russian Standard Time" id="0" connected="false"/>
Нужно ждать когда Финам обновится до этой версии.
Ух ты! Спасибо, Сергей! Я-то думал вы до сих пор праздники отмечаете :)
У меня пока версия 639, билд 7. А в течение какого времени Финам обновится? Он автоматом это делает?
-
Нет, Финам обновляется либо по окончании успешного тестирования, либо при каких-либо неотложных надобностях. Сроки непредсказуемы.
-
До сих пор версия 639, билд 7... Конечно не смертельно, но есть ли шанс, если я напишу в поддержку Финам, чтоб как-то "толкнуть" вопрос с обновлением версии сервера?
-
Не имеет смысла.
Внедрение новой версии задерживается по объективным причинам.