Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?
ФХЪРСап 14, 2024, 04:11:43 pm
Начало Помощь Поиск Войти Регистрация
Новости:

Просмотр сообщений

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Mike+

Pages: [1] 2
1
До сих пор версия 639, билд 7... Конечно не смертельно, но есть ли шанс, если я напишу в поддержку Финам, чтоб как-то "толкнуть" вопрос с обновлением версии сервера?

2
Исправлено в новой версии сервера:
<server_status sys_ver="640" build="5" server_tz="Russian Standard Time" id="0" connected="false"/>

Нужно ждать когда Финам обновится до этой версии.

Ух ты! Спасибо, Сергей! Я-то думал вы до сих пор праздники отмечаете :)
У меня пока версия 639, билд 7. А в течение какого времени Финам обновится? Он автоматом это делает?

3
Косяк "блуждал" от одной акции к другой, но сегодня всё нормализовалось..
Но если будет опять -- сообщу. Наверняка ведь разработчики переживают :-))

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

5
Сегодня глючат исторические свечи. Например ATUS (MMA):

callback: [<candles secid="10379" board="MCT" seccode="ATUS" period="2" status="1">
<candle date="29.12.2023 16:55:00" open="3.28" close="3.28" high="3.28" low="3.27" volume="22073"/>
<candle date="29.12.2023 17:00:00" open="3.28" close="3.3" high="3.31" low="3.28" volume="122164"/>
<candle date="29.12.2023 17:05:00" open="3.29" close="3.29" high="3.3" low="3.28" volume="58492"/>
<candle date="29.12.2023 17:10:00" open="3.3" close="3.3" high="3.3" low="3.28" volume="98007"/>
<candle date="29.12.2023 17:15:00" open="3.3" close="3.31" high="3.31" low="3.29" volume="103941"/>
<candle date="29.12.2023 17:20:00" open="3.31" close="3.31" high="3.34" low="3.29" volume="243518"/>
<candle date="29.12.2023 17:25:00" open="3.31" close="3.33" high="3.34" low="3.31" volume="43740"/>

<candle date="29.12.2023 17:30:00" open="3.34" close="3.33" high="3.34" low="3.32" volume="36689"/>
<candle date="30.12.2023 17:30:00" open="3.33" close="3.3" high="3.33" low="3.3" volume="53951"/>
<candle date="29.12.2023 17:30:00" open="3.31" close="3.32" high="3.33" low="3.31" volume="131661"/>
</candles>]

Последние три свечи должны быть одной свечой "29.12.2023 17:30:00" с объемом 222301.
Здесь же разделены на три: две "29.12.2023 17:30:00" и одна вообще с неверной датой 30.12.2023. Сумма объемов этих свечей как раз дает 222301.

Примерно такое же поведение заметил и для VTRS (MMA), ARQT (MMA). Похоже, что по многим инструментам.

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

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

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

Логи выслал.

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

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

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

9

Ничего подобного. Финам официально предлагает Коннектор как средство доступа: см. https://www.finam.ru/howtotrade/soft/tconnector/ Какие при этом он берет на себя обязательства - определяется вашим с ним договором, но скорее всего - достаточные.
Наши договорные отношения с Финамом не дают нам прав доступа ни к биржевым, ни к клиентским данным. Мы разработчики системы, ее эксплуатацией мы не занимаемся.
Мы благодарны вам за сообщение о проблеме и стараемся максимально быстро исправлять ошибки нашего софта. Но у нас для этого будет достаточно информации только тогда, когда техподдержка Финама озаботится вашей проблемой.

---------------------------------------
ОБратился в техническую поддержку Финама, вот переписка:

Я: Первый касается биржевых данных, получаемых мной через TransaqConnector. На форуме Connector'а сказали, чтобы я обращался в тех.поддержку Финама.
Я: Там технический вопрос в неверности временной зоны для получаемых исторических свечей. Можно ли отправить суть вопроса на e-mail почту поддержки? И вообще примут ли мой вопрос, касающийся именно TransaqConnector?

Оператор: Мы можем лишь предоставить логин и пароль для работы через транзак коннектор
Оператор: По работе самого приложения консультацию дать не можем

Я: Т.е. Финам не может оказать мне помощь, касающуюся работы с TransaqConnector? Обращаться нужно к разработчикам TransaqConnector?

Оператор: Да верно, так как это сторонее приложение
---------------------------------------

Произошло ровно то, о чем я и писал. То, что TransaqConnector официально предлагается к использованию Финамом, совершенно не означает, что он за него отвечает. Все, что дает Финам -- это токены для доступа к биржевому счету клиента, по которым клиент может получить доступ к БС через сторонние программы. Стандартная практика..

>> Наши договорные отношения с Финамом не дают нам прав доступа ни к биржевым, ни к клиентским данным.
TransaqConnector физически имеет доступ к биржевым данным и передает их клиенту. Потому что в противном случае, пользователи TransaqConnector не смогли бы запрашивать и получать исторические свечи, используя TC. Ваше ПО ведь берёт откуда-то эти данные. Вы в инструкции пишете, что: при utc_time = true время в свечах будет UTC. При запросах в выходные дни получаемые данные не соответствуют тому, что декларируется. Возникает вопрос: у КОГО вы берете эти данные и на каком этапе они "ломаются", то ли у источника, то ли у вас. Я готов писать тому, кто будет меня слушать. Финам слушать меня не захотел. Поэтому я обращаюсь за помощью к разработчикам.

Что мне делать, когда поведение вашего ПО в определенных условиях не соответствует заявленному? Логично же, что разработчик ПО должен подтвердить баг или опровергнуть, дать пояснения тому, кто задает вопрос. А при действительном наличии бага -- исправить его. Инструкцию к TransaqConnector писали вы, а не Финам. Значит разработчик, писавший инструкцию, ясно понимает что он получает от источника биржевых данных, конвертирует эти данные (опционально) и передает клиенту.

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

11
Вы Финаму в поддержку сообщали? Настройками таймзоны инструментов заведует Брокер.
Не сообщал. Просто я не совсем ясно представляю цепочку информационного взаимодействия.
Есть какие-то 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: для использования в торговых роботах и скринерах, а для этого получаемая информация должна быть корректной и соответствовать официальной инструкции. Ведь люди пользуются вашим ПО по вашей же инструкцией к нему. Поэтому и ожидается что-то вроде: "да, баг у нас, исправим" или "мы ни при делах, передаем без изменений то, что приходит от Брокера, но инструкцию поправим, чтобы люди учитывали этот нюанс".

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

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

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

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

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.

Pages: [1] 2


Войти

Powered by MySQL Powered by PHP Powered by SMF 2.0.10 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!