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

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

2014-11-04T11:29:42Z

Чтобы еще раз все понимали суть переделки насчет 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

Но если подойти с чисто теоретических позиций, при этом наплевав на прыгающую секунду, то достаточно...

2014-11-11T22:03:48Z

Но если подойти с чисто теоретических позиций, при этом наплевав на прыгающую секунду, то достаточно сохранять время биржи и метку географического положения биржи. Все остальные оффсеты можно восстановить из этих данных и базы tz, имеющей копеечный размер.
http://www.iana.org/time-zones
http://zoneinfo.codeplex.com/

PS. https://ru.wikipedia.org/wiki/Tz_database

Во-первых: под " локальное время" я имел ввиду локальное время биржи, т.е. по Вашему - время источни...

2014-11-11T19:19:44Z

Во-первых: под " локальное время" я имел ввиду локальное время биржи, т.е. по Вашему - время источника.

Михаил Сухов

Другими словами, для корректной работы с датами нужно знать: зону назначения (локальная), зону UTC (общеизвестная) и зона источника.

Если немного переформулировать то необходимо знать время UTC, текущее смещение для зоны источника, и текущее смещение для зоны назначения. Но зона назначения в общем случае заранее неизвестна. Например я сидя в Москве записываю данные Чигагской CME,чтоб использовать (как "поводырь") в тестировании алгоритма, работающего на MICEX и использующего данные сграбленные и их ftp. А потом я решаю а не потестировать ли мне этот алгоритм на данных сграбленных с сервера Сингапурской биржи... А там вдруг стрелки перевели... Т.е. получается хранить надо UTC и текущие смещения по всем крупным биржевым площадкам.

Во вторых: с UTC есть один ньюанс - два раза в год одна из минут может законно иметь от 59 до 61 секунды. Известны случаи, когда солидные серверные OS падали от изумления...

C TAI ( фр. Temps Atomique International) - Международное атомное время - такого не бывает.

http://www.leapsecond.com/java/gpsclock.htm

Ну так это практически то же самое, что хранить и локальное и UTC ;) Хранится время как раз в UTC. Н...

2014-11-11T17:41:31Z

transdex

Ну так это практически то же самое, что хранить и локальное и UTC ;)

Хранится время как раз в UTC. Но у локального и у UTC времени есть один недостаток - нет информации временной зоны источника. Другими словами, для корректной работы с датами нужно знать: зону назначения (локальная), зону UTC (общеизвестная) и зона источника.

transdex

Я бы еще добавил TAI, иначе как Вы собираетесь обрабатывать коррекционную секунду?

Я не знаю что такое TAI. Одна лишь ассоциация, но явно не та.

Ну так это практически то же самое, что хранить и локальное и UTC ;) Я бы еще добавил TAI, иначе как...

2014-11-11T17:22:17Z

Ну так это практически то же самое, что хранить и локальное и UTC ;) Я бы еще добавил TAI, иначе как Вы собираетесь обрабатывать коррекционную секунду?

В процессе переделки получилось следующее: 1. Из-за того, что тут неправильно начали интепретировать...

2014-11-11T13:17:41Z

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

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

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

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

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

2014-11-06T14:07:58Z

Михаил Сухов

pma37592

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

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

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

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

2014-11-05T17:03:47Z

pma37592

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

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

2014-11-05T11:31:58Z

transdex

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

А в чем смысл?

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

2014-11-04T20:44:42Z

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

А может оставить все как есть. Лучше оставить данные, как они приходят с коннектора, и если нужно то...

2014-11-04T16:09:54Z

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

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

2014-11-04T14:39:12Z

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

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

2014-11-04T07:52:06Z

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

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

2014-11-04T06:18:00Z

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

Всех приветствую. Провели в прошедшем месяце ревью нашего хранилища маркет-данных. Обнаружилась недо...

2014-11-03T17:42:37Z

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

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

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

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

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

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

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