IB 7.5 Как хр. процедуре в переменнной типа date обнулить время?

← →
novill © (2007-01-09 16:16) [0]

сабж

← →
Desdechado © (2007-01-09 16:31) [1]

peremen = NULL;

← →
novill © (2007-01-09 16:33) [2]

Уточню:
обнулить ТОЛЬКО время,
дату оставить без изменений.

← →
try (2007-01-09 16:54) [3]

DateValue=CAST(EXTRACT(DAY FROM DateValue)||"."||EXTRACT(MONTH FROM DateValue)||"."||EXTRACT(YEAR FROM DateValue) AS DATE);

← →
Ega23 © (2007-01-09 16:56) [4]

Это на TSQL. Общая идея: Cast as int и опять cast as datetime
declare @dt datetime Set @dt=getdate() Select Cast(Cast(@dt as int) as datetime)

← →
try (2007-01-09 17:19) [5]

> Ega23 © (09.01.07 16:56) [4]

Даты и времена к численным типам не кастуются никаким образом.

← →
novill © (2007-01-09 17:31) [6]

сработало [3]

спасибо

Путем некоторых махинаций пришел к несколько более простому виду

datevalue=CAST(cast(datevalue as varchar(11)) as date)

← →
Ega23 © (2007-01-09 17:32) [7]

> Даты и времена к численным типам не кастуются никаким образом.
>
>

В TSQL - как два байта переслать кастуются.

← →
Desdechado © (2007-01-09 17:46) [8]

[3] и [6] слишком зависимо от региональных настроек сервера и может работать неправильно (разделители не те, порядок месяцев-дней не тот, наличие-отстутствие лидирующих нулей в номере дня/месяца, короткий-длинный год).

← →
try (2007-01-09 17:49) [9]

> Ega23 © (09.01.07 17:32) [7]
> В TSQL - как два байта переслать кастуются.

Охотно верю. Только причём он тут?

> Desdechado © (09.01.07 17:46) [8]

[3] от региональных настроек не зависит никоем образом.

← →
Desdechado © (2007-01-09 17:54) [10]

гораздо правильнее методически вот так
select cast( "now" as TIMESTAMP ) - extract( hour FROM cast( "now" as timestamp ) )/24 - extract( minute FROM cast( "now" as timestamp ) )/24/60 - extract( second FROM cast( "now" as timestamp ) )/24/60/60 from rdb$database

← →
Desdechado © (2007-01-09 17:58) [11]

try (09.01.07 17:49) [9]
Ты бы попробовал сначала, ага?
Не первый раз уже такую пургу несешь...

← →
Ega23 © (2007-01-09 18:03) [12]

> Охотно верю. Только причём он тут?

Ты [4] внимательно читал, или как?

← →
Ega23 © (2007-01-09 18:05) [13]

> [3] от региональных настроек не зависит никоем образом.

Невооружённым взглядом видно, что зависит.
02.03.04 кастоваться по-разному будет.

← →
try (2007-01-09 18:11) [14]

> Desdechado © (09.01.07 17:54) [10]

Для третьего диалекта ещё проще
select cast( TimestampValue as date) from rdb$database :)))
Кстати, у тебя ошибка в [10]

> Ega23 © (09.01.07 18:03) [12]
> Ты [4] внимательно читал, или как?

Конечно. Но ещё внимательней я читал вопрос автора.
И выходит [4] совсем не в кассу....

> Ega23 © (09.01.07 18:05) [13]
> > [3] от региональных настроек не зависит никоем образом.
> Невооружённым взглядом видно, что зависит.02.03.04 кастоваться
> по-разному будет.

С этого места поподробнее. Желательно с доказательными примерами.

← →
try (2007-01-09 18:17) [15]

> Desdechado © (09.01.07 17:58) [11]
> try (09.01.07 17:49) [9]Ты бы попробовал сначала, ага?
> Не первый раз уже такую пургу несешь...

Я попробовал. А ты? Что получилось?

← →
Ega23 © (2007-01-09 18:28) [16]

> С этого места поподробнее. Желательно с доказательными примерами.

С ib-диалектами знаком слабо, но коли ты кастуешь строку к дате, то нельзя забывать, что дата 02.03.2004 может означать как 2 марта 2004, так и 3 февраля 2004.
И если в том-же MS SQL набрать следующую строку
Select Convert(varchar(10), Cast("02.03.2004" as datetime), 104), то получим как раз 3 февраля, а не 2 марта.
Опять же, я не сильный знаток ib-диалекта, но очень сильно подозреваю, что в FB такая же фигня. А вот во что он прикастует по-умолчанию - будет зависеть от региональных настроек.
Сейчас под рукой сервера нет, дома обязательно проверю.

← →
try (2007-01-09 18:50) [17]

> Ega23 © (09.01.07 18:28) [16]

Я понимаю твои сомнения.
Но дело в том, что формат день.месяц.год (именно в такой последовательности и именно с таким разделителем) является "внутренним стандартом" IB/FB/YA

← →
Desdechado © (2007-01-09 18:59) [18]

> Для третьего диалекта ещё проще
> select cast( TimestampValue as date) from rdb$database
Естественно. Здесь и спрашивать нечего, не то что отвечать.

> Кстати, у тебя ошибка в [10]
В чем?

> дело в том, что формат день.месяц.год (именно в такой последовательности и именно с таким разделителем)
> является "внутренним стандартом" IB/FB/YA
Ну-ну. Ты подставь туда минус, слэш, запятую, их комбинации и разглядишь их "стандарты". Может, когда-нибудь поймешь, чем чревато изменение недокументированного поведения "стандартов".

← →
Ega23 © (2007-01-09 19:01) [19]

> Но дело в том, что формат день.месяц.год (именно в такой
> последовательности и именно с таким разделителем) является
> "внутренним стандартом" IB/FB/YA

Да? Не знал. Спасибо, учту.
И тем не менее, datetime - суть число. Обнулить время - отбросить дробную часть. В Паскале - Trunc, в TSQL - прикастовать к int - это автоматом усечёт нули. В то, что datetime в IB/FB/YA не ксатуется в число - я просто не верю. Может не напрямую в int, а через промежуточный float, но это роли не меняет.

← →
Desdechado © (2007-01-09 19:08) [20]

Ega23 © (09.01.07 19:01) [19]
> В то, что datetime в IB/FB/YA не ксатуется в число - я просто не верю.
Нет, AFAIK. Там сложная упаковка даты-времени.
{--- тип TIMESTAMP в InterBase ---} T_ISC_DATE = LongInt; T_ISC_TIME = DWord; T_ISC_TIMESTAMP = record timestamp_date: T_ISC_DATE; timestamp_time: T_ISC_TIME; end; P_ISC_TIMESTAMP = ^T_ISC_TIMESTAMP; {--- распакованный для удобства TIMESTAMP ---} T_UNPACKED_TIMESTAMP = record fraction: DWord; // доля секунды second: Word; // 0..59 minute: Word; // 0..59 hour: Word; // 0..23 day: Word; // 1..31 month: Word; // 0..11 year: SmallInt; // calendar year minus 1900 end; P_UNPACKED_TIMESTAMP = ^T_UNPACKED_TIMESTAMP; // Calenders are divided into 4 year cycles: 3 Non-Leap years, and 1 leap year. // Each cycle takes 365*4 + 1 == 1461 days. // There is a further cycle of 100 4 year cycles. // Every 100 years, the normally expected leap year is not present. Every 400 years it is. // This cycle takes 100 * 1461 - 3 == 146097 days // The origin of the constant 2400001 is unknown. // The origin of the constant 1721119 is unknown. // The difference between 2400001 and 1721119 is the number of days // from 0/0/0000 to our base date of 11/xx/1858. (678882) // The origin of the constant 153 is unknown. // // This whole routine has problems with ndates // less than -678882 (Approx 2/1/0000). {----- упаковка данных в TIMESTAMP -----} // календарная дата в число дней от базовой даты function encode_isc_date( nYear: SmallInt; nMonth: Word; nDay: Word ): T_ISC_DATE; var nCentury, nYearInCentury: SmallInt; begin if( nMonth > 2 ) then nMonth := Word( nMonth - 3 ) else begin nMonth := Word( nMonth + 9 ); nYear := Word( nYear - 1 ); end; nCentury := nYear div 100; nYearInCentury := nYear mod 100; result := LongInt( 146097*nCentury ) div 4 + LongInt( 1461*nYearInCentury ) div 4 + ( 153*nMonth + 2 ) div 5 + nDay + 1721119 - 2400001; end; // время + десятые доли миллисекунд function encode_isc_time( var nTime: T_ISC_TIME; nHour: Word; nMinute: Word; nSecond: Word; nFraction: DWord ): Word; begin result := 0; // корректность параметров while( nSecond > 59 ) do begin Dec( nSecond, 60 ); Inc( nMinute ); end; while( nMinute > 59 ) do begin Dec( nMinute, 60 ); Inc( nHour ); end; while( nHour > 23 ) do begin Dec( nHour, 23 ); Inc( result ); // переполнение часов, сутки +1 end; // утоптать nTime := isc_time_seconds_precision *( ( nHour*60 + nMinute )*60 + nSecond ) + T_ISC_TIME( nFraction div ( 100*1000 ) ); end; // собственно компрессия в TIMESTAMP procedure encode_isc_timestamp( const unp_ts: P_UNPACKED_TIMESTAMP; isc_ts: P_ISC_TIMESTAMP ); var n: Word; begin isc_ts.timestamp_date := encode_isc_date( unp_ts.year, unp_ts.month, unp_ts.day ); n := encode_isc_time( isc_ts.timestamp_time, unp_ts.hour, unp_ts.minute, unp_ts.second, unp_ts.fraction ); Inc( isc_ts.timestamp_date, n ); end;

← →
Ega23 © (2007-01-09 19:13) [21]

> Нет, AFAIK. Там сложная упаковка даты-времени.

Подожди, это про timestamp. А datetime? Я просто очень давно с FB игрался, уже год не подходил, не помню нифига.

← →
Desdechado © (2007-01-09 19:16) [22]

Ega23 © (09.01.07 19:13) [21]
В 1 диалекте есть только DATE (он же TIMESTAMP в 3 диалекте).
В 3 диалекте есть отдельно DATE (просто дата) и TIME (просто время).

← →
try (2007-01-09 19:33) [23]

> Desdechado © (09.01.07 18:59) [18]
> > Кстати, у тебя ошибка в [10]
> В чем?

Неохота разбираться, в чём. Только результат выполнения запроса не соответствует ожидаемому (требуемому).

>> дело в том, что формат день.месяц.год (именно в такой
>> последовательности и именно с таким разделителем)> является
>> "внутренним стандартом" IB/FB/YAНу-ну.

>Ты подставь туда
> минус, слэш, запятую, их комбинации и разглядишь их "стандарты".
> Может, когда-нибудь поймешь, чем чревато изменение недокументированного
> поведения "стандартов".

Во-первых, "туда" ничего подставлять не надо - указанное стандартное представление говорит только о точке, а не о минусе, слэше, запятой, их комбинации.
Во-вторых, данный стандарт документирован (для IB). Давным-давно. Достаточно открыть эту самую документацию и посмотреть.
Единственное пожелание - не надо меня просить указать № страницы, главу, раздел и имя книги документации, где это описано. Сам найдёшь :)

← →
Desdechado © (2007-01-09 20:57) [24]

try (09.01.07 19:33) [23]
Съехал.
Собственно, как я и ожидал.

← →
try (2007-01-09 21:16) [25]

> Desdechado © (09.01.07 20:57) [24]
> try (09.01.07 19:33) [23]
> Съехал.Собственно, как я и ожидал.

Ты о чём?

Кстати
1. Что у тебя выдаёт запрос [10] ты так и не привёл.
2. Может я как-то не так понял выражение "Ты подставь туда минус etc"? Если тебе не сложно, поясни.

А то создается впечатление, что "Ты бы попробовал сначала, ага?" (c) Desdechado © (09.01.07 17:58) [11] ты адресуешь всем, кроме себя.

← →
Desdechado © (2007-01-09 22:25) [26]

запрос
select cast( "now" as TIMESTAMP ) - extract( hour FROM cast( "now" as timestamp ) )/24 - extract( minute FROM cast( "now" as timestamp ) )/24/60 - extract( second FROM cast( "now" as timestamp ) )/24/60/60 from rdb$database
возвращает 09.01.2007 0:00:00

Запросы с минусами, запятыми и слэшами - вообще винегрет:
1. select CAST(EXTRACT(DAY FROM cast("now" as timestamp))||"/" ||EXTRACT(MONTH FROM cast("now" as timestamp))||"/" ||EXTRACT(YEAR FROM cast("now" as timestamp)) AS timestamp) from rdb$database
дает 01.09.2007 0:00:00
2. select CAST(EXTRACT(DAY FROM cast("now" as timestamp))||"-" ||EXTRACT(MONTH FROM cast("now" as timestamp))||"-" ||EXTRACT(YEAR FROM cast("now" as timestamp)) AS timestamp) from rdb$database
дает 01.09.2007 0:00:00
3. select CAST(EXTRACT(DAY FROM cast("now" as timestamp))||"," ||EXTRACT(MONTH FROM cast("now" as timestamp))||"," ||EXTRACT(YEAR FROM cast("now" as timestamp)) AS timestamp) from rdb$database
дает 01.09.2007 0:00:00
4. select CAST(EXTRACT(DAY FROM cast("now" as timestamp))||"." ||EXTRACT(MONTH FROM cast("now" as timestamp))||"/" ||EXTRACT(YEAR FROM cast("now" as timestamp)) AS timestamp) from rdb$database
дает 09.01.2007 0:00:00
5. select CAST(EXTRACT(DAY FROM cast("now" as timestamp))||"/" ||EXTRACT(MONTH FROM cast("now" as timestamp))||"." ||EXTRACT(YEAR FROM cast("now" as timestamp)) AS timestamp) from rdb$database
дает 09.01.2007 0:00:00

Продолжить комбинировать можешь сам.

← →
try © (2007-01-09 22:47) [27]

> Desdechado © (09.01.07 22:25) [26]
> запросselect cast( "now" as TIMESTAMP ) - extract(
> hour FROM cast( "now" as timestamp ) )/24 - extract(
> minute FROM cast( "now" as timestamp ) )/24/60 - extract(
> second FROM cast( "now" as timestamp ) )/24/60/60from rdb$database возвращает
> 09.01.2007 0:00:00

Это наглая ложь.

> Продолжить комбинировать можешь сам.

Комбинировать начал ты, тебе и продолжать.
Я же утверждал и продолжаю утверждать, что ИБшном стандарте представления даты вида день.месяц.год используются ТОЧКИ и ТОЛЬКО ТОЧКИ. Никакой зависимости этого формата от региональных настроек НЕТ и НЕ БЫЛО.

← →
Desdechado © (2007-01-10 11:18) [28]

try © (09.01.07 22:47) [27]
> Это наглая ложь.
Не вижу доводов. За базар отвечать надо. А то можно и в бубен.

> Я же утверждал и продолжаю утверждать
B снова голословно. "Стандарт" должен быть документирован. Жду ссылку или цитату из официальной документации.

> Desdechado © (10.01.07 11:18) [28]
> Не вижу доводов.

Подъезжай ко мне, я тебе покажу, что твой запрос, выполненный под IB 7.5 c БД в 3 диалекте указанного тобою результата не выдаёт. Отсюда я делаю вывод, что ты лжешь.

> B снова голословно. "Стандарт" должен быть документирован.
> Жду ссылку или цитату из официальной документации.

Ну понятное дело, ЧСВ не позволяет тебе заглянуть в документацию. Позволяет только безаргументно наезжать.
Специально для тебя (обращаю внимание на выделенный фрагмент):

Casting a string to a date now permits strings of the form: "yyyy-mm-dd" "yyyy/mm/dd" "yyyy mm dd" "yyyy:mm:dd" "yyyy.mm.dd" In all of the forms above, you can substitute a month name or 3-letter abbreviation in English for the 2-digit numeric month. However, the order must always be 4-digit year, then month, then day. In previous versions of InterBase, you could enter date strings in a number of forms, including ones that had only two digits for the year. Those forms are still available in InterBase 7.5. If you enter a date with only two digits for the year, InterBase uses its "sliding window" algorithm to assign a century to the years. The following forms were available in earlier versions of InterBase and are still permitted in InterBase 7.5: "mm-dd-yy" "mm-dd-yyyy" "mm/dd/yy" "mm/dd/yyyy" "mm dd yy" "mm dd yyyy" "mm:dd:yy" "mm:dd:yyyy" "dd.mm.yy" "dd.mm.yyyy"

> Подъезжай ко мне
"на деревню дедушке"? Типичный отмаз при явном знании невыполнимости действия.

> указанного тобою результата не выдаёт
И что же он выдает? Другой результат? Ошибку? Слова, всё слова...

> Позволяет только безаргументно наезжать.
Я аргументы привожу здесь в отличие от некоторых, которые прячутся за словами "сам дурак" и "сам найдешь".

> Специально для тебя (обращаю внимание на выделенный фрагмент):
1. И что это за документ?
2. Где там сказано, что это стандарт, раз приведено еще куча разных возможностей?
3. Кстати, про запятые там ни слова, хотя они тоже работают. И про комбинации знаков-разделителей, о которых я писал. Хотя работают весьма своеобразно.

Обрати также внимание на результат обратного порядка:
select CAST(EXTRACT(YEAR FROM cast("now" as timestamp))||"." ||EXTRACT(MONTH FROM cast("now" as timestamp))||"." ||EXTRACT(DAY FROM cast("now" as timestamp)) AS timestamp) from rdb$database

> Desdechado © (10.01.07 13:39) [30]
> > Подъезжай ко мне"на деревню дедушке"? Типичный отмаз при
> явном знании невыполнимости действия.

Ну слов то тебе не достаточно.

> И что же он выдает? Другой результат? Ошибку? Слова, всё
> слова...

Тебе звуки нужны или тактильные ощущения? Или что?
Вот ещё немного слов, свеженьких, результат выполнения [10]:
2007-01-10 14:04:00.000 для текущей даты и времени 14:04:44
Т.е. видим, что вычитаемые в выражении запроса [10] не сильно повлияли на уменьшаемое. Почему? Потому, что выполняется неявное преобразование типов вычитаемых. А именно к типу integer, что при указанном делении даёт ноль для часов и минут. Хорошо, исправим эту твою ошибку. напишем 24.0 и 60.0 Что получаем? Вот это: 2007-01-10 2:07:00.000 для текущей даты и времени 14:07:06.
А ты смеешь утверждать (слова, всё слова), что время должно получаться 00:00:00.000.

> Я аргументы привожу здесь в отличие от некоторых, которые
> прячутся за словами "сам дурак" и "сам найдешь".

Это здесь твои аргументы?

Desdechado © (09.01.07 17:58) [11]
Desdechado © (09.01.07 20:57) [24]

К вопросу о прятании за словами.

> 1. И что это за документ?
> 2. Где там сказано, что это стандарт, раз приведено еще куча разных возможностей?
> 3. Кстати, про запятые там ни слова, хотя они тоже работают. И про комбинации знаков-разделителей, о которых я писал. Хотя работают весьма
своеобразно.

1. Это Release Notes InterBase 7.5 написанный и опубликованный Borland.
2. Эта куча строго описана и конечна. Является стандартом, определённым официальным документом.
3. Естественно. Нет общепринятых видов с запятыми. И Borland не обязан их поддерживать и документировать. А если они как-то работают, то это побочное недокументированное явление.

> Нет общепринятых видов с запятыми.

0 or 100 (*) Default mon dd yyyy hh:miAM (or PM)
1 101 USA mm/dd/yy
2 102 ANSI yy.mm.dd
3 103 British/French dd/mm/yy
4 104 German dd.mm.yy
5 105 Italian dd-mm-yy
6 106 - dd mon yy
7 107 - Mon dd, yy
8 108 - hh:mm:ss
- 9 or 109 (*) Default + milliseconds mon dd yyyy hh:mi:ss:mmmAM (or PM)
10 110 USA mm-dd-yy
11 111 JAPAN yy/mm/dd
12 112 ISO yymmdd
- 13 or 113 (*) Europe default + milliseconds dd mon yyyy hh:mm:ss:mmm(24h)
14 114 - hh:mi:ss:mmm(24h)
- 20 or 120 (*) ODBC canonical yyyy-mm-dd hh:mi:ss(24h)
- 21 or 121 (*) ODBC canonical (with milliseconds) yyyy-mm-dd hh:mi:ss.mmm(24h)
- 126(***) ISO8601 yyyy-mm-dd Thh:mm:ss:mmm(no spaces)
- 130* Kuwaiti dd mon yyyy hh:mi:ss:mmmAM
- 131* Kuwaiti dd/mm/yy hh:mi:ss:mmmAM

вишь, сколько дофига?
А офицальный Windows-стандарт - в целой части количество дней с 01.01.1900, а дробная - количество часов-минут-секунд-миллисекунд и т.п.
А офицальный UNIX-стандарт - количество секунд с какого-то-там-числа-196-какого-то-года.
А у Borland - в целой части количество дней с 30.12.1899, а дробная - количество часов-минут-секунд-миллисекунд и т.п.

Стандартов - дофига. Строковых - вообще дофига.

> Ega23 © (10.01.07 14:50) [32]

Я говорил о форматах представления, а не хранения.
Из приведённых тобой в ответ на
> Нет общепринятых видов с запятыми.
я вижу только 7 107 - Mon dd, yy
Утверждать, что это общепринятый формат я бы не стал.

> Кстати, ты попробовал, что хотел?

Нет, у меня ребёнок заболел, пол-ночи с женой вокруг него прыгали. Не до того было.
А на работе у меня только MS SQL.

> Я говорил о форматах представления, а не хранения.
> Из приведённых тобой в ответ на
> > Нет общепринятых видов с запятыми.
> я вижу только 7 107 - Mon dd, yy
> Утверждать, что это общепринятый формат я бы не стал.
>

Ну правильно, представления. Я вообще свой могу придумать.
Просто меня всего передёргивает от твоего способа приводить к строке (которая суть формат представления; пусть даже и внутренне-принятый), а потом обратное приведение к числу.

> Ega23 © (10.01.07 15:07) [36]
> Просто меня всего передёргивает от твоего способа приводить к строке
> (которая суть формат представления; пусть даже и внутренне-
> принятый),

Согласен, несколько необычно. Но, тем не менее, именно так и делают. Причем "зубры" и авторитеты IB/FB/YA, о чём можно почитать на конференциях, напр. на sql.ru

> а потом обратное приведение к числу.

Да не к числу, а к датновремннному типу.

> try (10.01.2007 15:01:33) [33]

В системах с недельным/месячным циклом так можно считать.

Не вижу смысла в дальнейшем споре.
Я приводил в [10] методически правильный подход. Умеющий думать да доведет его до ума, если запрос вдруг почему-то (?) не работает (у меня работает, и это не странно).
А "внутренние стандарты" - слишком скользкая штука, склонная к изменению от версии к версии. Да и не факт, что он не будет зависеть от локали сервера, клиента или их взаимосоединения.
Думаю, автор вопроса сам выберет удобный ему путь и вспомнит о дискуссии, наступив на грабли.

За сим прощаюсь.

ЗЫ "Каждый может заблуждаться, но только глупцы упорствуют в своих заблуждениях" (с) кто-то из древних греков

> try (10.01.2007 15:19:37) [37]

> Но, тем не менее, именно так и делают. Причем "зубры" и авторитеты IB/FB/YA, о чём можно почитать на конференциях, напр. на sql.ru

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

IB 7.5 Как хр. процедуре в переменнной типа date обнулить время? Найти похожие ветки