Временные метки хранилища. StockSharp

Временные метки хранилища

11/3/2014

Всех приветствую.

Провели в прошедшем месяце ревью нашего хранилища маркет-данных. Обнаружилась недоработка в плане хранения данных - отсутствует признак временной зоны. Проблема на текущий момент не сильно актуальная (большинство живет в зоне +3 и торгует на московской бирже, поэтому никакой сдвиг не нужен), но фиксить нужно сейчас.

Для тех, кто не совсем понял о чем речь приведу простой пример. Вы пишите данные торгов московской биржи. Время, что в Москве равно 10:00, будет записано как 10:00. Далее, вы переезжаете на Камчатку, прихватив с собой диск с историей. Запускаете программу, она рисует в истории 10:00 как локальное время. Но это неправильно. Вы уже в другой временной зоне, и записанные данные должны учитывать это.

Основная проблема, как это ни странно, вовсе не в хранилище. А в коннекторах к торговым системам. Сейчас отправляется DateTime, который в себе содержит только метку времени (без временной зоны). В хранилище понять уже невозможно в какой зоне получена метка времени. Вариантов решения два:

1. Для всех данных, что имеют метку времени (а это почти все) вместо DateTime использовать DateTimeOffset. Плюс в том, что внешне ничего не изменится. Минус - потребление памяти увеличиться.

2. Перейти на UTC. На истории все метки времени будут в UTC, поэтому время будет единым (и для Москвы и для Камчатки). Но будет несколько непривычно.

Мне лично нравится ваариант 2. Но пока переделки не вступили в силу, можно обсудить. Релиз будет через неделю. Отмечу особо - это не тот страшный релиз, о котором я писал в чате. Тот будет во второй половине ноября.

Tags:

StockSharp

Thanks:

1 2 >

RomSunZ

Date: 11/4/2014

логичнее сделать UTC

Thanks:

devruss

Date: 11/4/2014

я тоже за UTC. С таймзоной все проще - достаточно вначале программы задать UTC offset для своей таймзоны и время будет как обычно

Thanks:

Mikhail Sukhov

Date: 11/4/2014

Чтобы еще раз все понимали суть переделки насчет UTC. Эта переделка предполагает, что теперь ВСЕ коннекторы будут возвращать даты в UTC формате.

Другими словами, если раньше из QuikTrader получали сделку на открытие с меткой времени, например, 10:00:00.234, то после фикса время будет 07:00:00.234 AM. Если в роботе будет захардкодена проверка времени, то теперь эта проверка должна учитывать временную зону. По-умолчанию время создается в Local тайм-зоне. Сравнение двух объектов DateTime учитывает и разницу во временных зонах (07:00:00.234 AM по UTC будет больше, чем 10:00:00.000 +3).

Но, если у кого на компьютере временная зона будет НЕ соответствовать биржевой, то будет коллизия, которую нужно устранять логикой кода. Например, я торгую на московской бирже, но живу на Камчате (на компьютере у меня разница от Москвы +7 часов). Если я прописываю в коде 10:00, то это означает 10:00 по локальному времени (тоесть 3 часа ночи по Москве). Другими словами, или задавать время 17:00 (если нужно указать 10 по Москве) или создавать DateTime сразу в UTC.

Само хранилище при этом не изменяется (там все равно время хранится числом, а что именно означает число хранилищу без разницы).

Релиз, включающий перевод времени на UTC, будет отмечен в Release Notes http://stocksharp.com/forum/4139/S--API-4-2/ а так же в Твиттере https://twitter.com/StockSharp и Контакте https://vk.com/stocksharp

Thanks:

devruss

Date: 11/4/2014

А что будет с историей Гидры, в которой хранятся данные во временной зоне коннектора?

Thanks:

pma37592

Date: 11/4/2014

А может оставить все как есть.
Лучше оставить данные, как они приходят с коннектора, и если нужно то дописать временную зону уже в приложении.
Если перейдете на UTC, то нужно хранить все изменения в правилах изменения временной зоны. А у нас за последние 3 года правила менялись 3 раза.
А Windows выдает только последнее изменение правил. Так что данные, которые были сохранены скажем в 2000 году, не получится правильно отобразить, т.к. правила изменения смещения уже менялись. Так что каждый раз когда изменяются правила перехода на летнее или зимнее время, нельзя правильно отобразить предыдущие данные, которые были сохранены со старыми правилами. И тогда возникнет путаница.
Придется все изменения правил перехода на летнее и зимнее время хранить. А нужен такая проблема?

Thanks:

rtDen

transdex

Date: 11/4/2014

А почему нельзя хранить и локальное и UTC?

Thanks:

pma37592

Date: 11/5/2014

transdex

А почему нельзя хранить и локальное и UTC?

А в чем смысл?

Thanks:

Mikhail Sukhov

Date: 11/5/2014

pma37592

А Windows выдает только последнее изменение правил. Так что данные, которые были сохранены скажем в 2000 году, не получится правильно отобразить, т.к. правила изменения смещения уже менялись.

Я не знаю что такое "последнее изменение правил", но Windows хранит историю изменения Daylight saving time.

Thanks:

pma37592

Date: 11/6/2014

Михаил Сухов

pma37592

Я не знаю что такое "последнее изменение правил", но Windows хранит историю изменения Daylight saving time.

Не каждая версия windows, и не по каждой временной зоне. Я бы вот протестил этот вопрос прежде, чем приступать к реализации.
А еще как только microsoft перестает поддерживать очередную версию windows, настройка Daylight saving time головная боль пользователей windows.
Лучше не надеяться на microsoft в этом вопросе.

Thanks:

Mikhail Sukhov

Date: 11/11/2014

В процессе переделки получилось следующее:

1. Из-за того, что тут неправильно начали интепретировать временные зоны, я пришел к выводу, что эта информация для некоторых просто непонятна. Поэтому перевод всего и вся в UTC просто невозможен. Появится сразу проблемы с отображением в непривычной временной зоне время заявок, сделок и т.д.

2. Со стороны кода робота необходимо все метки времени так же переводить в UTC (вариант, что маркет-дату мы получаем в UTC, а в заявках дату экспирации отправляем в локальном - ведет к еще большим ошибкам).

В связи с этим переход с DateTime на DateTimeOffset оказался безальтернативным. По мере переделки мне даже начал испонировать данных подход. Во-первых, с внешней стороны мало что меняется (логи, таблицы - все пишется в привычной временной зоне). Можно использовать как и раньше локальное время. Во-вторых, можно использовать одновременно подход с разными временными зонами. Например, делать запрос времени в локальном формате или в UTC - и интепретироваться это будет одинаково.

Thanks:

1 2 >

Attach files by dragging & dropping, , or pasting from the clipboard.