Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
TIMESTAMP_FORMAT
|
|||
|---|---|---|---|
|
#18+
Всем привет! В таблице имеются записи следующие записи time_stmt ----------------------------- 2006-08-26-16.24.30.601000 2006-08-26-16.25.02.362000 2006-08-26-16.30.40.656000 2006-08-26-16.31.03.462000 2006-08-26-16.31.40.912000 2006-08-26-16.32.03.628000 2006-08-26-16.33.05.138000 2006-08-26-16.33.08.363000 2006-08-26-16.34.08.838000 Нужно выбрать записи из этой таблицы. select time_stmt from stmt where time_stmt > timestamp_format('2006-01-01 0:00:00','YYYY-MM-DD HH24:MI:SS') но увы запрос ругается на функцию в которой неправильный формат указан. Все работало до момента когда не была изменена системная дата, после чего все перестало работать. Но есть другой вариант выборки данных: select time_stmt from stmt where time_stmt > '2006-01-01 0:00:00' вот только есть сомнения по этому поводу, на сколько коректен этот запрос? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 13:22 |
|
||
|
TIMESTAMP_FORMAT
|
|||
|---|---|---|---|
|
#18+
Код: plaintext тогда уж так : select time_stmt from stmt where CHAR(DATE(time_stmt), ISO ) > '2006-01-01' AND CHAR(TIME(time_stmt), JIS ) > '0:00:00' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 13:46 |
|
||
|
TIMESTAMP_FORMAT
|
|||
|---|---|---|---|
|
#18+
warIord Код: plaintext тогда уж так : select time_stmt from stmt where CHAR(DATE(time_stmt), ISO ) > '2006-01-01' AND CHAR(TIME(time_stmt), JIS ) > '0:00:00' Ну уж не так. Контрпример - '2006-01-02 00:00:00'. Лично я чаще пользуюсь выражениями вида time_stmt > TIMESTAMP(DATE('2006-01-01'), TIME('00:00:00')), поскольку до долей секунд мне дела нет, но и time_stmt > '2006-01-01-00.00.00.000000' должно прокатить (при соответствующих языковых настройках на клиенте!). YYYY-MM-DD понимается и при русских настройках, и, по-видимому, универсален. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 14:08 |
|
||
|
TIMESTAMP_FORMAT
|
|||
|---|---|---|---|
|
#18+
А насколько будет универсален запрос Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 14:31 |
|
||
|
TIMESTAMP_FORMAT
|
|||
|---|---|---|---|
|
#18+
2 Victor Metelitsa ну и в чем проблема : ... > '00:00:00' работает как часы, безо всяких ориентаций на системный формат даты вы свели все к сравнению дат, я - к лексикографическому сравнению строк, результат один ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 14:33 |
|
||
|
TIMESTAMP_FORMAT
|
|||
|---|---|---|---|
|
#18+
warIord2 Victor Metelitsa ну и в чем проблема : ... > '00:00:00' работает как часы, безо всяких ориентаций на системный формат даты вы свели все к сравнению дат, я - к лексикографическому сравнению строк, результат один Я же привёл контрпример. time_stmt > '2006-01-01 0:00:00' - это "все после полуночи 1-го января 2006", а у вас - "все после полуночи 1-го января 2006, исключая все последущие полуночи". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 14:44 |
|
||
|
TIMESTAMP_FORMAT
|
|||
|---|---|---|---|
|
#18+
да, согласен, разбиение на дату и время - логическая ошибка select time_stmt from stmt where CHAR(time_stmt, JIS ) > '2006-01-01 00:00:00' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 14:56 |
|
||
|
TIMESTAMP_FORMAT
|
|||
|---|---|---|---|
|
#18+
http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/admin/r0000859.htm Самое удобное, быть может, "A string of length 14 must be a string of digits that represents a valid date and time in the form yyyyxxddhhmmss, where yyyy is the year, xx is the month, dd is the day, hh is the hour, mm is the minute, and ss is the seconds", а 2006-08-26-16.25.02.362000 можно представить как (http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/admin/r0000736.htm#labdur) TIMESTAMP('20060826162502') + 362000 MICROSECONDS. Форматы дат/времён в http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/admin/r0008474.htm Про системную дату я не понял - какое она имеет отношение к конверсии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 14:56 |
|
||
|
TIMESTAMP_FORMAT
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa YYYY-MM-DD понимается и при русских настройках, и, по-видимому, универсален. Я тоже этот формат использую , при неявной конвертации, но пока не долго :) Меня всё мучае вопрос - Этот формат такой же как в MS SQL Server 'YYYYMMDD' , который понимается всегда правильно и не зависит от настроек? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 15:07 |
|
||
|
TIMESTAMP_FORMAT
|
|||
|---|---|---|---|
|
#18+
В функции DATE() требуется valid string representation of date, а они приведены в http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/admin/r0008474.htm В том числе и YYYY-MM-DD. А если учесть, что таких коллизий, какие есть с MM/DD/YYYY и DD/MM/YYYY (впрочем, второе не перечислено в списке valid), не имеется, то можно использовать без боязни. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 15:20 |
|
||
|
TIMESTAMP_FORMAT
|
|||
|---|---|---|---|
|
#18+
к слову, запрос странноват, время '2006-01-01 0:00:00' это уже 2006-01-01, поэтому логичнее включать полночь, тоесть >= у меня встречный вопрос к автору, чистое любопытство, почему отбрасываеся полночь, правила биллинга или что-то в этом роде? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 17:17 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=33955587&tid=1605160]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 378ms |

| 0 / 0 |
