Свечи не попадают в диапазон дат в запросе

[alexandr-v]

Пример запроса:

GET https://api-invest.tinkoff.ru/openapi/sandbox/market/candles?figi=BBG005DXJS36&from=2020-09-01T07:00:00Z&to=2020-09-02T07:00:00Z&interval=day

в ответ возвращается свеча с меткой времени: "time": "2020-09-02T07:00:00Z" вопрос: а где свеча с "time": "2020-09-01T07:00:00Z" ?

было бы понятно если бы наоборот работало) но следующий запрос выдает тот же результат

GET https://api-invest.tinkoff.ru/openapi/sandbox/market/candles?figi=BBG005DXJS36&from=2020-09-01T06:00:00Z&to=2020-09-02T07:00:00Z&interval=day

свеча с "time": "2020-09-01T07:00:00Z" возвращается только так:

GET https://api-invest.tinkoff.ru/openapi/sandbox/market/candles?figi=BBG005DXJS36&from=2020-09-01T00:00:00Z&to=2020-09-02T07:00:00Z&interval=day

это баг или фича?)

[shapeless-space]

Попробуйте запросить данные с TZ +03:00

[alexandr-v]

Попробуйте запросить данные с TZ +03:00

Не очень понял а зачем? Неважно в какой зоне передается метка времени же. Вне зависимости от зоны она указывает на одну точку на оси времени. Ну и как видно из примеров выше, свеча появляется только с разницей во времени свечи и запросом в -7 часов, тут явно проблема не в зоне.

[alexandr-v]

да и ваше апи не принимает дату и время с часовым поясом на вот это все в поле from:

2020-09-01T10:00:00.000+03:00 2020-09-01T10:00:00.000+0300 2020-09-01T10:00:00.000+03 2020-09-01T10:00:00+03:00 2020-09-01T10:00:00+0300 2020-09-01T10:00:00+03

один ответ:

{
  "trackingId": "6dae8704c27d73ec",
  "payload": {
    "message": "Неверный формат поля 'from' в запросе",
    "code": "MALFORMED_QUERY_PARAMETER"
  },
  "status": "Error"
}

я даже не знаю как еще передать часовой пояс в ISO8601

[Fatal1ty]

я даже не знаю как еще передать часовой пояс в ISO8601

Попробуй микросекунды передавать.

[alexandr-v]

Попробуй микросекунды передавать.

Вы серьезно это все?) Какие микросекунды?) 2020-09-01T10:00:00.0+03:00 2020-09-01T10:00:00.00+03:00 2020-09-01T10:00:00.000+03:00 2020-09-01T10:00:00.0000+03:00 2020-09-01T10:00:00.00000+03:00 2020-09-01T10:00:00.000000+03:00 ... это все приводит к "message": "Неверный формат поля 'from' в запросе". Если тут пишут, что принимаем дату в ISO8601, тогда нужно поддерживать этот стандарт полностью, либо указать конкретно в каком формате необходимо слать дату и время с зоной и удалить ISO8601 в документации вообще)

Причем тут вообще зона?) Моя проблема простая: я запрашиваю свечи от 2020-09-01T07:00:00Z и свеча с меткой 2020-09-01T07:00:00Z мне не возвращается, более того при запросе от 2020-09-01T06:00:00Z, 2020-09-01T05:00:00Z, 2020-09-01T04:00:00Z, 2020-09-01T03:00:00Z, 2020-09-01T02:00:00Z и 2020-09-01T01:00:00Z свечи как бы тоже нет)) Тут все даты и время в одной зоне и свечи и запроса)) А вот если спросить от 2020-09-01T00:00:00Z, то она появляется в ответе

Это явный баг и даже два)

[alexandr-v]

как по мне так 2020-09-01T06:00:00Z МЕНЬШЕ 2020-09-01T07:00:00Z так же как и 6 < 7

[alexandr-v]

а вот еще...

GET https://api-invest.tinkoff.ru/openapi/sandbox/market/candles?figi=BBG005DXJS36&from=2020-09-01T07:00:00Z&to=2020-09-01T07:00:00Z&interval=day

ответ:

{
  "trackingId": "34d0c75083947ff2",
  "payload": {
    "message": "[to]: Bad candle interval: from=2020-09-02T00:00:00Z to=2020-09-02T00:00:00Z expected from 1 day to 1 year",
    "code": "VALIDATION_ERROR"
  },
  "status": "Error"
}

интересные вещи у вас в апи нахожу порой))) я понимаю суть ошибки) что даты должны быть разнесены минимум на 1 день и т.д., но все же... это как надо дату парсить чтобы 2020-09-01T07:00:00Z стало вот этим 2020-09-02T00:00:00Z ?)

[kitMP]

Похоже, у меня такая же проблема, а сегодня ещё обнаружил такое чудо, что не отдаётся свеча в дату From. Если увеличиваю запрос на From+1 предыдущий From выдаётся, From+1 нет.

[alexandr-v]

Похоже, у меня такая же проблема, а сегодня ещё обнаружил такое чудо, что не отдаётся свеча в дату From. Если увеличиваю запрос на From+1 предыдущий From выдаётся, From+1 нет.

сочувствую... но корень проблемы я нашел, осталось городить костыли или ждать фикса неизвестно сколько) учитывая парсинг этого 2020-09-01T07:00:00Z в это 2020-09-02T00:00:00Z в моем случае становится понятно почему не попадает свеча от 2020-09-01T07:00:00Z, а попадает только при запросе с from=2020-09-01T00:00:00Z

самое интересное продолжая тему с таймзонами, я попробовал пример из свагера с датой 2019-08-19T18:38:33.131642+03:00

https://api-invest.tinkoff.ru/openapi/sandbox/market/candles?figi=BBG005DXJS36&from=2019-08-19T18:38:33.131642+03:00&to=2019-08-19T18:38:33.131642+03:00&interval=day

ответ:

{
    "trackingId": "0eaaaa0a7cdc07bb",
    "payload": {
        "message": "Неверный формат поля 'from' в запросе",
        "code": "MALFORMED_QUERY_PARAMETER"
    },
    "status": "Error"
}

что ж...

[kitMP]

Пардон, в моём предыдущем сообщении From надо заменить на To. А какой костыль тут можно использовать, чтобы это правильно парсилось?

[alexandr-v]

Пардон, в моём предыдущем сообщении From надо заменить на To. А какой костыль тут можно использовать, чтобы это правильно парсилось?

Ну можно например запрашивать данные с какой то дельтой ∆, чтоб учитывать это. Если вам нужны данные от даты from=Х, то в реальном запросе к апи нужно указать дату Х - ∆. Желательно сделать это в каком то промежуточном слое, чтобы быстро убрать, если пофиксят. С to примерно так же.

[Fatal1ty]

u/openapi/sandbox/market/candles?figi=BBG005DXJS36&from=2020-09-01T07:00:00Z&to=2020-09-02T07:00:00Z&interval=day

в ответ возвращается свеча с меткой времени: "time": "2020-09-02T07:00:00Z"

вопрос: а где свеча с "time": "2020-09-01T07:00:00Z" ?

Мне вполне очевидно, что хранение дневных свеч привязано к началу суток, поэтому в запросе надо указывать 2020-09-01T00:00:00Z. Дневная свеча подразумевает под собой оперирование не временем, а датой, которую стандартные библиотеки переводят в дату и время с 00:00:00. Стоит ли ожидать появление дневной свечи, передавая параметром 7 утра — спорный вопрос. Возможно, разработчики решили, что не стоит, тут я их могу понять.

Если запрашивать свечи с интервалом меньше дня, например, часовые, то можно передавать 2020-09-01T07:00:00Z, чтобы получить первую свечу в торговом сессии.

самое интересное продолжая тему с таймзонами, я попробовал пример из свагера с датой 2019-08-19T18:38:33.131642+03:00

https://api-invest.tinkoff.ru/openapi/sandbox/market/candles?figi=BBG005DXJS36&from=2019-08-19T18:38:33.131642+03:00&to=2019-08-19T18:38:33.131642+03:00&interval=day

ответ:

{
    "trackingId": "0eaaaa0a7cdc07bb",
    "payload": {
        "message": "Неверный формат поля 'from' в запросе",
        "code": "MALFORMED_QUERY_PARAMETER"
    },
    "status": "Error"
}

Очень странно. У меня такой запрос выдает не ошибку формата данных, а логическию "[to]: Bad candle interval: from=2019-08-20T00:00:00Z to=2019-08-20T00:00:00Z expected from 1 day to 1 year". Очевидно, что тут вы пытаетесь запросить дневные свечи для интервала меньше 1 дня.

Вы серьезно это все?) Какие микросекунды?) 2020-09-01T10:00:00.0+03:00 2020-09-01T10:00:00.00+03:00 2020-09-01T10:00:00.000+03:00 2020-09-01T10:00:00.0000+03:00 2020-09-01T10:00:00.00000+03:00 2020-09-01T10:00:00.000000+03:00 ... это все приводит к "message": "Неверный формат поля 'from' в запросе". Если тут пишут, что принимаем дату в ISO8601, тогда нужно поддерживать этот стандарт полностью, либо указать конкретно в каком формате необходимо слать дату и время с зоной и удалить ISO8601 в документации вообще)

Перепробовал все варианты и ошибки про формат поля 'from' не получил. Вы уверены в том, что правильный запрос отправляете? Всегда работало, сколько я работал с этим API.

[alexandr-v]

Мне вполне очевидно, что хранение дневных свеч привязано к началу суток, поэтому в запросе надо указывать 2020-09-01T00:00:00Z. Дневная свеча подразумевает под собой оперирование не временем, а датой, которую стандартные библиотеки переводят в дату и время с 00:00:00. Стоит ли ожидать появление дневной свечи, передавая параметром 7 утра — спорный вопрос. Возможно, разработчики решили, что не стоит, тут я их могу понять.

Ничего логичного и тем более очевидного тут нет. У свечи есть конкретная метка времени 2020-09-01T07:00:00Z, и если я запрашиваю свечи с 2020-09-01T06:59:59.999Z или даже с 2020-09-01T07:00:00Z логично ожидать что она будет в ответе. А вот если бы у свечи была бы метка 2020-09-01T00:00:00Z, то я бы согласился. Но это не так. Представим себе ситуацию, есть дробный атрибут у свечи со значением 5.5. Я хочу выбрать все свечи у которых этот атрибут больше 5.4, но на сервере почему то есть округление для этого параметра, мой параметр округляется до 6, и в итоге в выборку не попадает 5.5. Это очень странное поведение. Уж извините.

Очень странно. У меня такой запрос выдает не ошибку формата данных, а логическию "[to]: Bad candle interval: from=2019-08-20T00:00:00Z to=2019-08-20T00:00:00Z expected from 1 day to 1 year". Очевидно, что тут вы пытаетесь запросить дневные свечи для интервала меньше 1 дня.

Я это делаю намерено что, и прекрасно знаю что есть такое ограничение, чтобы увидеть во что парсится дата в итоге. И очень странно, что разработчики считают что 2020-09-01T07:00:00Z можно округлить до 2020-09-02T00:00:00Z, если это так.

Перепробовал все варианты и ошибки про формат поля 'from' не получил. Вы уверены в том, что правильный запрос отправляете? Всегда работало, сколько я работал с этим API.

Правильный на все 100, в реальности он выглядит так:

GET https://api-invest.tinkoff.ru/openapi/sandbox/market/candles?figi=BBG005DXJS36&from=2020-09-01T10%3A00%3A00.000+03%3A00&to=2020-09-01T10%3A00%3A00.000+03%3A00&interval=day

Хочу заметить это правильный запрос, и что 2020-09-01T10:00:00.000+03:00 стало этим 2020-09-01T10%3A00%3A00.000+03%3A00. И если проблема в этом) то это еще печальнее... Могу только дать ссылку на RFC2396, там описано какие символы зарезервированы в URL и как их надо экранировать, не говоря уже о кириллице и т.п. Все нормальные http клиенты делают это налету.

[Fatal1ty]

Хочу заметить это правильный запрос, и что 2020-09-01T10:00:00.000+03:00 стало этим 2020-09-01T10%3A00%3A00.000+03%3A00. И если проблема в этом) то это еще печальнее... Могу только дать ссылку на RFC2396, там описано какие символы зарезервированы в URL и как их надо экранировать, не говоря уже о кириллице и т.п. Все нормальные http клиенты делают это налету.

Погодите, вы сами вручную экранируете что ли перед тем, как отправить запрос? Если бы вы как раз пользовались нормальным http клиентом, то у оригинального параметра "2020-09-01T10:00:00.000+03:00" символ "+" преобразовался бы в "%2B", т.к. по указанному вами же RFC2396 символ "+" является зарезервированным символом. В итоге получилось бы 2020-09-01T10%3A00%3A00.000%2B03%3A00

[alexandr-v]

Погодите, вы сами вручную экранируете что ли

Нет) но написав это я заметил как раз +, не экранирует почему то Postman и Idea (Rest client) :( Да проблема в +, с этим признаюсь, виноват, не заметил)) если так 2020-09-01T10%3A00%3A00.000%2B03%3A00 то работает

[kitMP]

Обнаружил такое непонятное поведение. Здесь DaysDiff = -1. Код candles = SBContext.MarketCandlesAsync(figi, startDate.Date.AddDays(DaysDiff).Date, endDate.Date.AddDays(DaysDiff).Date, CandleInterval.Day).Result.Candles; по разному возвращает свечи. Например, для тикера "D" в даты 12.09.1988-17.09.1988 возвращает правильное количество свечей с учётом выходных: curl -X GET "https://api-invest.tinkoff.ru/openapi/sandbox/market/candles?figi=BBG000BGVW60&from=1988-09-12T00%3A00%3A00%2B00%3A00&to=1988-09-17T00%3A00%3A00%2B00%3A00&interval=day" Ответ: { "trackingId": "5076c4addd257298", "payload": { "candles": [ { "o": 14.2083, "c": 14.0833, "h": 14.2083, "l": 14.0417, "v": 429900, "time": "1988-09-13T07:00:00Z", "interval": "day", "figi": "BBG000BGVW60" }, { "o": 14.125, "c": 14.2083, "h": 14.2083, "l": 14.0417, "v": 227100, "time": "1988-09-14T07:00:00Z", "interval": "day", "figi": "BBG000BGVW60" }, { "o": 14.2083, "c": 14.125, "h": 14.2083, "l": 14.125, "v": 294300, "time": "1988-09-15T07:00:00Z", "interval": "day", "figi": "BBG000BGVW60" }, { "o": 14.0833, "c": 14.1667, "h": 14.2083, "l": 14.0833, "v": 540900, "time": "1988-09-16T07:00:00Z", "interval": "day", "figi": "BBG000BGVW60" } ], "interval": "day", "figi": "BBG000BGVW60" }, "status": "Ok" }

Теперь для тикера "RDS.A" в даты 14.08.2019 - 17.08.2019: этот же код возвращает на одну свечу меньше, хотя в свагере ответ правильный и включает в себя три свечи - 14, 15, 16. Где может быть подвох?

[alexandr-v]

Где может быть подвох?

Без примера запроса и ответа сложно что то сказать, возможно в стране чья эта акция был праздник/не рабочий день. А если в свагере возвращает, значит разные запросы у вас скорее всего

[kitMP]

Сейчас и в свагере не возвращает: curl -X GET "https://api-invest.tinkoff.ru/openapi/sandbox/market/candles?figi=BBG000QXSSS6&from=2019-08-14T00%3A00%3A00%2B00%3A00&to=2019-08-16T00%3A00%3A00%2B00%3A00&interval=day" -H "accept: application/json" Ответ: { "trackingId": "ce2c889af2873714", "payload": { "candles": [ { "o": 56.94, "c": 56.39, "h": 56.94, "l": 56.38, "v": 526802, "time": "2019-08-14T07:00:00Z", "interval": "day", "figi": "BBG000QXSSS6" }, { "o": 55.18, "c": 55.09, "h": 55.18, "l": 54.98, "v": 478482, "time": "2019-08-15T07:00:00Z", "interval": "day", "figi": "BBG000QXSSS6" } ], "interval": "day", "figi": "BBG000QXSSS6" }, "status": "Ok" } И дело не в празднике, т.к. эта свеча есть: Запрос: https://api-invest.tinkoff.ru/openapi/sandbox/market/candles?figi=BBG000QXSSS6&from=2019-08-16T00%3A00%3A00%2B00%3A00&to=2019-08-19T00%3A00%3A00%2B00%3A00&interval=dayОтвет:{ "trackingId": "c68a0f9c5883e96d", "payload": { "candles": [ { "o": 55.46, "c": 55.56, "h": 55.56, "l": 55.09, "v": 423248, "time": "2019-08-16T07:00:00Z", "interval": "day", "figi": "BBG000QXSSS6" } ], "interval": "day", "figi": "BBG000QXSSS6" }, "status": "Ok" } Это то, о чём я писал, что не возвращается дневная свеча в дату поля "to". Видно в обоих запросах. При этом, если сделать запрос для тикера D: https://api-invest.tinkoff.ru/openapi/sandbox/market/candles?figi=BBG000BGVW60&from=1988-09-13T00%3A00%3A00%2B00%3A00&to=1988-09-15T00%3A00%3A00%2B00%3A00&interval=day Ответ: { "trackingId": "9d03c89049182f86", "payload": { "candles": [ { "o": 14.125, "c": 14.2083, "h": 14.2083, "l": 14.0417, "v": 227100, "time": "1988-09-14T07:00:00Z", "interval": "day", "figi": "BBG000BGVW60" }, { "o": 14.2083, "c": 14.125, "h": 14.2083, "l": 14.125, "v": 294300, "time": "1988-09-15T07:00:00Z", "interval": "day", "figi": "BBG000BGVW60" } ], "interval": "day", "figi": "BBG000BGVW60" }, "status": "Ok" } Обратная ситуация - нет свечи за первую дату в запросе - 13 сентября 1988 г., а есть за последнюю. Свечи нет именно в ответе, если изменить начальную дату на 12.09.1988, то эта свеча будет первой в ответе, а не будет уже свечи за 12.09.1988. Т.е. в зависимости непонятно от чего, не хватает то первой, то последней свечи. Может, конечно,что-то не так в формате даты в запросах, но мне не очевидно что именно....

[kitMP]

@NikitaMelnikov , хотелось бы от вас получить комментарий по поводу моих запросов через свагер в предыдущем сообщении.

[shapeless-space]

Завели внутреннюю задачу, связано с https://github.com/TinkoffCreditSystems/invest-openapi/issues/177 https://github.com/TinkoffCreditSystems/invest-openapi/issues/329

[kitMP]

@NikitaMelnikov , можете назвать ориентировочные сроки? Кейс 177 от 19 апреля, т.е. задача уже старше квартала...

[shapeless-space]

Сроков пока нет, коллеги занимаются решением

[kitMP]

@NikitaMelnikov , до сих пор не осилили кейс?

[AlexanderVolkovTCS]

@kitMP в процессе