Unix-время

Внимание

Для участия в обсуждениях и оформления подписки на новые сообщения форума вам необходимо зарегистрироваться.
Главная » Основные форумы » Программирование на языке Lua
Страницы: 1
RSS
Unix-время
 
#1
20.11.2019 20:48:17
Если на ваши сервера приходят данные с Unix-временем ,
то предлагаю сделать доступным такой формат тоже
во избежание излишних трансляций на каждом трейде
для автоматизированных систем,
коль скоро QLua тут для этого.

Там где возможно.
Спасибо.
 
 
#2
21.11.2019 05:57:30
те : нужен long чтобы собрать число формата yyddmmhhmmsszzz
но лучше сразу unix-время на каждом трейде
с минимумом преобразований
 
 
#3
21.11.2019 14:00:58
Добрый день.
Правильно понимаем, что вы хотите, чтобы мы добавили новое поле unix_datetime,  (например, на сделках или заявках)  т.к. Вам не удобен формат Lua таблицы?
 
 
#4
21.11.2019 14:20:11
Цитата
Egor Zaytsev написал:
Правильно понимаем, что вы хотите, чтобы мы добавили новое поле unix_datetime,  (например, на сделках или заявках)
да, а вы пропатчили 5.1 для long?

Цитата
Egor Zaytsev написал:
т.к. Вам не удобен формат Lua таблицы?
дело не в удобстве - пара строк не проблема, а в лишних временных затратах на преобразование или сборку своих полей из таблицы для  массовых скоплений
можете сами проверить затраты на сотне тысяч записей: передернуть времена в long отжирает как быстрая сортировка

++ причина апнуть до 5.3
 
 
#5
21.11.2019 18:14:16
Цитата
новичок написал:
а вы пропатчили 5.1 для long?
Если, как я понял, речь о целых числах в луа, так они как intptr_t определяются и на 64 битах должны быть 64-битные из коробки, а вот если заменить в заголовке на long, то получим внезапно 32 бита, ибо на винде long 32-битный. Или о другом чем-то?
 
 
#6
21.11.2019 19:32:00
Цитата
Anton написал:
Цитата
новичок написал:
а вы пропатчили 5.1 для long?
Если, как я понял, речь о целых числах в луа, так они как intptr_t определяются и на 64 битах должны быть 64-битные из коробки, а вот если заменить в заголовке на long, то получим внезапно 32 бита, ибо на винде long 32-битный. Или о другом чем-то?
лично у меня нет таких вопросов - есть и более прямой способ

здесь предложение реализовать то, как это должно быть
зачем плоскую инфу загонять в табличный вид
который все равно потом нужно обратно в плоский вид
ну пусть с сервера дают пока что в double
чтобы обходиться без преобразования типов и структур
потом в 5.3 это будет более просто в long

собсно моё дело - предложить
 
 
#7
21.11.2019 19:42:30
Цитата
новичок написал:
зачем плоскую инфу загонять в табличный вид
С этим-то согласен. Правда, есть сомнения, что едет оно в плоском виде, как бы не в текстовом. До сервера-то по фиксу точно в текстовом, дальше надо у арки (конфиденциальную инфу) выспрашивать, где оно у них в число превращается и превращается ли вообще.
 
 
#8
21.11.2019 20:19:21
Цитата
Anton написал:
где оно у них в число превращается и превращается ли вообще
не просто превращается, а в dat файлах оно у них уже в FILETIME формате
те считай всё уже тут, а потом бац и ... /* ... во вторую смену ... (с) */
... в табличку

ткчт и делать то особенно ничего не нужно - нужно просто кое-чего НЕ делать

:)

Цитата
Anton написал:
как бы не в текстовом.
уточним для любопытствующих, что речь конечно не про символы, а про по-байтовую передачу :)
 
 
#9
22.11.2019 05:46:18
Цитата
новичок написал:
не просто превращается, а в dat файлах оно у них уже в FILETIME формате
Можно тогда предположить, что едет в этом же формате. Это, так сказать, хорошая новость. А плохая - в дабл файлтайм как есть не полезет, там мантисса всего 52 бита, если ее всю заполнить единицами, будет 1615-04-10 11:59:22.737, что как бы малость не хватает. То есть конвертить все равно придется, либо в офисный формат, который в дабле (но парсить будет удовольствие то еще, плюс цель избежать сложной конвертации не достигается), либо урезать до микросекунд (делить файлтайм на 100), тогда максимум будет 3028-02-19 22:57:53.704, либо, как изначально предлагалось, в unix time, что по сути то же самое обрезание, только уже до секунд, вопросы и пожелания "отдайте микросекунды" гарантированы.
Цитата
новичок написал:
речь конечно не про символы
В фиксе как раз они самые, поле UTCTimestamp выглядит типа
Код
60=YYYYMMDD-HH:MM:SS.sssssssssSOH
 
 
#10
22.11.2019 06:27:54
FIX: неправду выше написал. До микросекунд это делить файлтайм на 10, и максимум получится 1743-09-18 23:53:47.370, т.е. опять не хватает. Если предположить, что "время в десятках микросекунд" не удовлетворяет из-за "странности" единиц, придется резать до миллисекунд, т.е. делить на 10000.
 
 
#11
22.11.2019 07:55:19
Цитата
новичок написал:
не просто превращается, а в dat файлах оно у них уже в FILETIME формате
ну тогда всеравно в time_t конвертить нужно.
а) откуда уверенность что FILETIME
б) тогда уж лутше в луа отдавать FILETIME (ежели прям без конверсий)

не?
 
 
#12
22.11.2019 08:08:15
Цитата
Imersio Arrigo написал:
тогда уж лутше в луа отдавать FILETIME (ежели прям без конверсий)
Выше написал, почему не получится. У луа 5.1 нет целого типа как такового, есть LUA_NUMBER, который double. А в double файлтайм не полезет.

Поразмышлял на эту тему и решил, что лучшим форматом был бы unixtime с микросекундами. Он лезет в double без потери точности и вычисляется из файлтайма достаточно легко:
Код
static int hibit(unsigned long long ull) throw () // нужно только для ассерта в отладочном режиме
{
   int result = 0;
   while((ull >>= 1) != 0)
      ++result;
   return result;
}

double filetime_to_unix_time_with_microseconds(const ::FILETIME * pft) throw ()
{
   assert(pft);
   const unsigned long long uoffset = 116444736000000000ULL;
   const unsigned long long ftime =
      (static_cast<unsigned long long>(pft->dwHighDateTime) << 32) | pft->dwLowDateTime;
   const unsigned long long utime = (ftime - uoffset) / 10;
   assert(::hibit(utime) < 52);
   return static_cast<double>(utime);
}
 
 
#13
22.11.2019 08:15:29
Цитата
Anton написал:
что лучшим форматом был бы unixtime с микросекундами.
Какой смысл, если все равно нужно конвертить? Ничем не лучше существующей схемы. А больше форматов - больше конвертаций.
Если только для удобства получателя.

И еще, мне кажется, что полный "unixtime с микросекундами" в дабл не влезет. Можно раздельно сунуть unixtime, и отдельно микросекунды.
 
 
#14
22.11.2019 08:30:07
Цитата
Imersio Arrigo написал:
мне кажется, что полный "unixtime с микросекундами" в дабл не влезет.
Лезет в ближайшие 200 лет, а там, глядишь, и квик переписывать пора.
Цитата
Imersio Arrigo написал:
Ничем не лучше существующей схемы.
Это конверт на сишной стороне, можно считать бесплатный. Распихивание по таблице луа и потом вытаскивание из нее на порядки тяжелее.
 
 
#15
22.11.2019 08:34:37
Цитата
Anton написал:
Лезет в ближайшие 200 лет, а там, глядишь, и квик переписывать пора.
Так-то unixtime закончится уже через 19 лет...
 
 
#16
22.11.2019 08:39:30
Цитата
Imersio Arrigo написал:
Цитата
Anton написал:
Лезет в ближайшие 200 лет, а там, глядишь, и квик переписывать пора.
Так-то unixtime закончится уже через 19 лет...
32-битный. Если до 64 бит расширить, будет вечным. По сути разница с файлтаймом в а) точке отсчета и б) минимальном шаге.
 
 
#17
22.11.2019 09:11:37
Цитата
Anton написал:
Лезет в ближайшие 200 лет,
Проверил. В дабл входит вплоть до 2241 года. Потом начинаются проблемы с точностью :)
 
 
#18
22.11.2019 09:38:54
Цитата
Imersio Arrigo написал:
Проверил. В дабл входит вплоть до 2241 года. Потом начинаются проблемы с точностью :)
Ага, сам точную границу не искал, посмотрел только, что лет 200 влезает. Кстати, в моем коде надо в ассерте < заменить на <=, а то он уже на 52 битах сигналит, рановато.

С другой стороны, подумал о варианте с микросекундами отдельно. Тоже свои плюсы есть, часть с секундной точностью совпадает с форматом времени луа, что может быть удобно для кого-то, ну и в случае чего умножить на миллион и прибавить микросекунды не так и затратно. На один пуш в таблицу больше на стороне квика, на один поп больше на стороне скрипта. Не сказать, чтобы смертельная цена. Нужны еще мнения в общем, кому как кажется удобнее.
 
 
#19
22.11.2019 11:49:55
Цитата
Imersio Arrigo написал:
а) откуда уверенность что FILETIME
нету а..аще никакой :) , но ...

когда берем по адресу из .dat файла 8 байт как лонг
и потом это делим на 10 млн и вычитаем 11644473600L,
то хлоп ..  и получается пхальное юникс_тайм в секундах

вот и подумалось
могу быть неправ, ессно
Цитата
Imersio Arrigo написал:
б) тогда уж лутше в луа отдавать FILETIME (ежели прям без конверсий)
ну с версии 5.3, когда будет лонг , то - да
Цитата
Imersio Arrigo написал:
ну тогда всеравно в time_t конвертить нужно.
ну лонг в лонг не так уж и затратно :)
 
 
#20
22.11.2019 12:02:01
Цитата
Anton написал:
В фиксе как раз они самые, поле UTCTimestamp выглядит типа
бито-байты в железе и картинки на мониторе из табличек различаем?
вам сиплюсплюс лоб напек наверное :)

а ..а, ну точно
Цитата
static int hibit(unsigned long long ull) throw () // нужно только для ассерта в отладочном режиме {    int result = 0;    while((ull >>= 1) != 0)       ++result;    return result; }  double filetime_to_unix_time_with_microseconds(const ::FILETIME * pft) throw () {    assert(pft);    const unsigned long long uoffset = 116444736000000000ULL;    const unsigned long long ftime =       (static_cast<unsigned long long>(pft->dwHighDateTime) << 32) | pft->dwLowDateTime;    const unsigned long long utime = (ftime - uoffset) / 10;    assert(::hibit(utime) < 52);    return static_cast<double>(utime); }
https://www.youtube.com/watch?v=2h_vI7IXZqg&feature=youtu.be&t=145

пс: г...ггг

ппс: веселых выходных, братья.
 
 
#21
22.11.2019 13:00:00
Цитата
новичок написал:
картинки на мониторе
Именно что в дампе так выглядит. На правую колоночку тоже иногда стоит поглядывать, любопытные вещи там видны.
 
 
#22
22.11.2019 15:41:33
Цитата
Anton написал:
Цитата
новичок написал:
картинки на мониторе
Именно что в дампе так выглядит. На правую колоночку тоже иногда стоит поглядывать, любопытные вещи там видны.
https://www.youtube.com/watch?v=XH5u3-AZT80
 
 
#23
23.11.2019 13:24:16
Цитата
Egor Zaytsev написал:
Добрый день.
Правильно понимаем, что вы хотите, чтобы мы добавили новое поле unix_datetime,  (например, на сделках или заявках)  т.к. Вам не удобен формат Lua таблицы?
Если все же решите добавить это поле, не забудьте добавить и дробную часть (микросекунды)
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
 
#24
23.11.2019 14:48:38
Цитата
s_mike@rambler.ru написал:
Цитата
Egor Zaytsev написал:
Добрый день.
Правильно понимаем, что вы хотите, чтобы мы добавили новое поле unix_datetime,  (например, на сделках или заявках)  т.к. Вам не удобен формат Lua таблицы?
Если все же решите добавить это поле, не забудьте добавить и дробную часть (микросекунды)
Михаил,

нам нужно лонг, а микросекунды уже есть  и это

файлтайм/10-11644473600 000 000
 
 
#25
23.11.2019 16:41:36
Цитата
Imersio Arrigo написал:
а) откуда уверенность что FILETIME
Код
#include <stdio.h>

int main(void)
{
    FILE *fd;

    fd = fopen ( "alltrade.dat", "rb");
    if ( !fd ) return -1;
    
    fseek(fd, 500, 0);
    
    long dt;
    fread(&dt, 8, 1, fd);
   
    printf("\n epoch_time (ms) = %ld\n", dt/10000-11644473600000L);
   
    fclose(fd);
    
    return 0;
}
 
 
#26
28.11.2019 14:52:15
Добрый день.
Сообщите, какое будем в итоге регистрировать пожелание?
 
 
#27
29.11.2019 08:49:27
Цитата
Egor Zaytsev написал:
Добрый день.
Сообщите, какое будем в итоге регистрировать пожелание?
Доступ к параметру _дата_время_ в виде числа, а не таблицы/структуры.
 
 
#28
29.11.2019 10:25:10
Цитата
новичок написал:
Цитата
Egor Zaytsev написал:
Добрый день.
Сообщите, какое будем в итоге регистрировать пожелание?
Доступ к параметру _ дата_время _ в виде числа, а не таблицы/структуры.
Здравствуйте!

Ваше пожелание зарегистрировано.  Мы постараемся рассмотреть его и  сообщить Вам результаты анализа. Впоследствии, по результатам анализа,  будет приниматься решение о реализации пожелания в будущих версиях ПО.
 
 
Страницы: 1
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2024,
ARQA Technologies
Наверх