Неверный часовой пояс в сообщении <candles>

[Mike+]

Добрый вечер.

Обнаружил, что буквально в последний день-два-три в ответе <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 в свечах был верный. Что делать? Косяк ведь, не?

Спасибо.

[Mike+]

Провел эксперимент и запросил свечи на российский ВТБ:

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.

[Mike+]

Сегодня свечи для MCT стали с верной UTC-шной таймзоной приходить. Видимо, исправили.

[Mike+]

Началось опять: время в свечах не 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.

[Mike+]

Ребята-разработчики, вы где?

[Дмитрий]

Вы Финаму в поддержку сообщали? Настройками таймзоны инструментов заведует Брокер.

[Mike+]

Вы Финаму в поддержку сообщали? Настройками таймзоны инструментов заведует Брокер.

Не сообщал. Просто я не совсем ясно представляю цепочку информационного взаимодействия.
Есть какие-то 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).

Наши договорные отношения с Финамом не дают нам прав доступа ни к биржевым, ни к клиентским данным. Мы разработчики системы, ее эксплуатацией мы не занимаемся.

> Ну не буду же я писать в Финам "Ребята, вы там похоже намудрили с таймзоной при запросе биржевых данных...

Да, не стОит. Лучше написать то, что вы наблюдаете, а выводы оставить им.

Мы благодарны вам за сообщение о проблеме и стараемся максимально быстро исправлять ошибки нашего софта. Но у нас для этого будет достаточно информации только тогда, когда техподдержка Финама озаботится вашей проблемой.

[Mike+]

OK, попробую написать в их тех.поддержку

[Mike+]

Ничего подобного. Финам официально предлагает Коннектор как средство доступа: см. 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
Хорошо бы посмотреть логи за выходной, когда произошла ошибка и в понедельник, когда все нормализовалось.

[Mike+]

Логи коннектора на момент ошибки сохранились? xdf и ts-логи особенно интересуют. Если да - пришлите пожалуйста на support@transaq.ru
Хорошо бы посмотреть логи за выходной, когда произошла ошибка и в понедельник, когда все нормализовалось.

Спасибо, Сергей. Логи вышлю. Я как раз сегодня хотел проверить до полуночи и после. Сейчас (пятница) таймзона нормальная и в ts-логе вроде ничего подозрительного. Как наступит суббота, попробую еще раз. Если баг опять проявится -- сразу же вышлю логи "здорового человека" и "алкоголика"

[Mike+]

В пятницу в 23:58 таймзона была корректная. И даже при наступлении субботы в 00:30 тоже все было корректно. Когда проверил в субботу в 13:13, то косяк уже был, таймзона в свечах стала UTC-3.

Логи выслал.

P.S. На всякий случай напомню, что баг есть только для инструментов MCT, для board TQBR (российских) этого бага нет: все свечи приходят строго в UTC.

[Mike+]

Ради эксперимента в команде connect изменил параметр utc_time на "false" и зона стала UTC в свечах, снятых в субботу. Ставлю обратно utc_time = "true" -- опять косяк, зона съезжает на 3 часа назад...

А DLL-ка получает от источника уже разложенное по таймзоне время или time_t (секунды с Эпохи)? Если time_t, то может вместо календарного (или дополнительно к календарному) добавить в свечи тэг с величиной time_t? Это бы решило проблему)) Те, кто хочет читать календарное, -- берет в расчет календарное, а кто-то будет брать секунды с Эпохи и сам переводить в календарное по местной таймзоне..

[Mike+]

Ребята, по посяку с таймзоной не разбирались?