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


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

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

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

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

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

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

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

Теги:


Спасибо:


1 2  >
RomSunZ

Фотография
Дата: 04.11.2014
Ответить


логичнее сделать UTC
Спасибо:

devruss

Фотография
Дата: 04.11.2014
Ответить


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

Mikhail Sukhov

Фотография
Дата: 04.11.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
Спасибо:

devruss

Фотография
Дата: 04.11.2014
Ответить


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

pma37592

Фотография
Дата: 04.11.2014
Ответить


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

transdex

Фотография
Дата: 04.11.2014
Ответить


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

pma37592

Фотография
Дата: 05.11.2014
Ответить


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

А в чем смысл?
Спасибо:

Mikhail Sukhov

Фотография
Дата: 05.11.2014
Ответить


pma37592 Перейти

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


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

pma37592

Фотография
Дата: 06.11.2014
Ответить


Михаил Сухов Перейти
pma37592 Перейти

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


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

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

Mikhail Sukhov

Фотография
Дата: 11.11.2014
Ответить


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

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

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

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

Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy