Firebird + IBX: проблемы с timestamp и TDateTimeField

Merlin · Сообщение **Merlin** » 28 авг 2006, 17:49

kdv писал(а): to Merlin: я к тому, что миллисекунды это не 0.nnnn, а 0.nnn. То есть даже то что в IB было 15 лет, все равно "не соответствует".

Ну-с, начинать тогда уж надо с того, что в IB таймштамп - это два инта (и, если мне не изменяет склероз, то не только в IB, а и в большинстве других СУБД), а в Delphi - дабл, так что соответствовать они не могут в принципе, независимо от всяких там функций-визуализаторов и знаков после запятой. Приложения, построенные в предположениях о соответствии клиентского и серверного представления, живут как на вулкане в принципе. Я это поле граблей прошёл году эдак в 96м.

Сообщение **kdv** » 28 авг 2006, 18:10

для начала, я хочу услышать о числе миллисекунд в TimeStamp в C++ и в .Net.

Сообщение **kdv** » 28 авг 2006, 18:32

кстати, я полез в архив fb-devel почитать ту битву за миллисекунды, однако не понял, почему current_timestamp по умолчанию возвращает миллисекунды, а не по current_timestamp(4) ?
т.е. как бы то ни было, умолчательное поведение ломает существующие приложения.

кроме того - миллисекунды это миллисекунды, и хранение в Delphi (и как я понял в .Net и еще разных местах) timestamp как double делает
а) возможным обработку на клиенте только миллисекунд, а не десятых долей миллисекунд
б) невозможным конструкции типа field = :param, без обрезания миллисекунд перед сохранением.

p.s. на возгласы "а где был ты" или "опять?" могу ответить только то, что читаю fb-devel редко, и не всегда бываю против подобных нововведений. Но тут как-то кривовато получается...

Merlin · Сообщение **Merlin** » 28 авг 2006, 18:58

kdv писал(а): p.s. на возгласы "а где был ты" или "опять?" могу ответить только то, что читаю fb-devel редко, и не всегда бываю против подобных нововведений. Но тут как-то кривовато получается...

А ты што, Delphi писАл?

Где был, где был... Где все, в объективной реальности, данной нам в ощущениях. Есть такие-сякие инструменты, и они вот такие и работают вот так. И надо на них решать свои задачи, выбирая пути и алгоритмы, учитывая особенности этих инструментов. Управлять процессами термоядерного синтеза вряд ли кто с помощью Delphi пытался

Сообщение **kdv** » 28 авг 2006, 20:02

фиг с ним, с синтезом. я вот чего не пойму - договорились же в fb-devel (в марте, куча писем со словом current_timestamp в теме), что current_timestamp продолжает возвращать время без десятых миллисекунд. И тётя Аня была за, и вообще. И тут вдруг...

Сообщение **kdv** » 28 авг 2006, 20:07

цитирую Бузаджи:
"В плюсах это говно работает как положено. Милисекунды при этом подходе не теряются. В общем вся беда от апишных функций декодирования. Там выходная структура вообще не подразумевает долей секунд."

правда, я все равно пока не понял, как решается double <> quad.
то бишь, TDateTimeField.asTimeStamp.

Merlin · Сообщение **Merlin** » 28 авг 2006, 20:28

kdv писал(а):фиг с ним, с синтезом. я вот чего не пойму - договорились же в fb-devel (в марте, куча писем со словом current_timestamp в теме), что current_timestamp продолжает возвращать время без десятых миллисекунд. И тётя Аня была за, и вообще. И тут вдруг...

Ну а если вдуматься - а не один ли хрен, по большому счёту? Выборки типа "на дату", "на этот час" на таймштампе отродясь делались диапазонными условиями. Где он нужен на равенство-то? Таймштамп в ПК имеет смысл только для логов, для order by, и каждый логовод, один раз споткнувшись и разобравшись, от этого отказывается. Кому нужна была точность до миллисекунд или долей миллисекунд - прыгали с бубном вокруг пресловутой цены деления шкалы в 54,925 мсек и разбирались в этом до тонкостей. В Дельфи, имея в виду, скорее всего вовсе не связь с СУБД, а всякие там инженерные расчёты, сунули его в дабл, обеспечив нефиксированную цену деления, гораздо более точную для расчётов с малыми величинами временных интервалов, не вытаскиваемых из СУБД, а рассчитываемых по каким-нибудь там T=S/V или SQRT(S/A) и полагая, что с большими на эти хвостики будет наплевать. По той же причине и функции форматирования дат, а не временных интервалов, в Дельфи пофигистически к ним относятся - один чорт в последнем разряде будет свистопляска. Что датавремя на равенство в СУБД искать нельзя - это же известный факт природы, устанавливаемый, по традиции, каждым человеком сначала опытным путём, а потом осмысливаемый

dimitr · Сообщение **dimitr** » 28 авг 2006, 22:23

1) никакого решения о том, что current_timestamp должен возвращать целые секунды не было. Были попытки лоббирования совместимости, на что были даны ответы.

2) current_timestamp(4) возвращает *три* знака точности (последний знак всегда ноль) в текущей реализации, т.к. нет легкой возможности на всех платформах гарантировать бОльшую точность. А возвращать то три знака, то четыре в зависимости от платформы считаем зловредным. В будущем точность может улучшиться.

3) в C/C++ таймштампы бывают разные. Структура tm имеет секундную точность, timeb - миллисекундную, timeval - микросекундную. Стандартом является первая.

Вообще, с API вопрос довольно спорный. Есть тип ISC_TIMESTAMP, структура которого вроде как документирована. И есть helper-функции isc_encode/isc_decode, которые позволяют превращать ISC_TIMESTAMP в struct tm (стандарт в С) и наоборот. В такой ситуации обвинять API в отсутствии поддержки миллисекунд довольно глупо, особенно на Delphi, где struct tm - это вообще чужеземный тип. Разве кто заставляет работать через анус, когда можно работать сразу с ISC_TIMESTAMP. Для паскаля он настолько же "родной", как и struct tm.

Andrew Sagulin

Немного не в тему, но с TDateTime я огребал даже без использования СУБД. В CDR-файле (биллинг) есть поля, которые хранят дату и время в разобранном виде (с точностью до секунд). Я с помощью EncodeDateTime преобразовывал это время в TDateTime, а затем сравнивал с границей суток. И время от времени у меня данные почему-то неправильно переносились в другие сутки. Потом до меня дошло, что часто время разговора, произошедшего точно в начале суток, выглядело как 32768,9999 вместо 32769. Вышел из положения, добавляя к времени одну сотую секунды перед сравнением.
По моему, в разнообразных системах учёта и регистрации гораздо полезнее дискретное время с заранее заданной точностью, чем то якобы непрерывное TDateTime, которое предлагает Borland Delphi.