временные типы полей

micolo

Новичок
временные типы полей

Доброго времени суток!
У меня вопрос относительно полей типов DATETIME, TIMESTAMP и т.д. Скаким из этих типов лучше всего работать если нужно например сортировать по этому полю, или сделать выборку в промежутке с такой даты по такую с точностью до секунды и др.
Или же они 'равноценны' в этом отношении.
Спасибо!
 

Фанат

oncle terrible
Команда форума
по поводу поля и т.д. ничего не могу сказать - никогда о таком не слышал.
по поводу же остальных двух могу сказать, что они совершенно неравноценны.
DATETIME служит для записи в БД даты и времени.
а поле TIMESTAMP служит для автоматического фиксирования времени изменения строки в таблице.
а вообще - читай доки, они рулез

-~{}~ 17.10.06 09:16:

И совсем они не временные, а очень даже постоянные
 

micolo

Новичок
:)
да не хватает ударения....
а если серьёзно, раньше я преоброзовывал данные времени с которыми нужно было манипулировать в unixtime и работал с ними, проблем не было.
теперь в частном случае я не могу по определённым причинам это преоброзовыть и решил попробывать использовать поле с типом timestamp.
Вот и спрашиваю не будет проблем с выборкой даты, типа нули в месяце он будет считать за нули или месяц и т.д.
 

Фанат

oncle terrible
Команда форума
ударение здесь не нужно.
поскольку в слове "временные" ударение бывает только в одном месте - на первый слог.

Ты читал вообще, что я тебе написал? К чему ты написал все эти рассуждения про свои проблемы с датой? Какая связь с тем, что я написал выше?
 

Observer

Новичок
Проблемы будут, когда ты решишь что-то поменять в записи. Поле с типом TIMESTAMP примет значение текущего времени.
Тут рассуждения ни к чему.
Используйте DATETIME.
 

pdi

Новичок
Если мне не изменяет память, в версиях выше 4.1 можно указать какое по счету в таблице поле типа TIMESTAMP устанвливается в NOW() при UPDATE/REPLACE или указать, что оно не изменяется, в отличии от предыдущих версий, где первое поле всегда устанавливалось в NOW() (кроме, пожалуй, явного указания `datetime_field` = `datetime_field`).

TIMESTAMP сохраняет временную зону
DATETIME может сохранять доли секунд

А лучше просто почитать Это
 

Фанат

oncle terrible
Команда форума
Если мне не изменяет память, в версиях выше 4.1 можно указать какое по счету в таблице поле типа TIMESTAMP устанвливается в NOW() при UPDATE/REPLACE или указать, что оно не изменяется, в отличии от предыдущих версий,
если мне не изменяет здравый смысл и логическое мышление, то непонятно, КАКОЙ СМЫСЛ в таком "указании".
временную зону
ты тоже чурка нерусская? это называется ЧАСОВОЙ ПОЯС!
А слова "временнОй" в современном русском языке нет.
 

pdi

Новичок
Автор оригинала: Фанат
если мне не изменяет здравый смысл и логическое мышление, то непонятно, КАКОЙ СМЫСЛ в таком "указании".
В том, что
Автор оригинала: Фанат
а поле TIMESTAMP служит для автоматического фиксирования времени изменения строки в таблице.
не всегда так, может и применяется для других целей

Автор оригинала: Фанат
ты тоже чурка нерусская?
С каких пор оскорблять правилами форума разрешено? :0

Автор оригинала: Фанат
это называется ЧАСОВОЙ ПОЯС!
Это синонимичные понятия, хотя соглашусь, "часовой пояс" более употребим. Смотреть Здесь

Автор оригинала: Фанат
А слова "временнОй" в современном русском языке нет.
С каких пор оно из него пропало? Учить русский Здесь
 

Фанат

oncle terrible
Команда форума
не всегда так, может и применяется для других целей
ну, расскажи мне, родной, для каких целей оно может применяться, таких, с которыми бы не справились другие, предназначенные для этого типы.
Это синонимичные понятия, хотя соглашусь, "часовой пояс" более употребим. Смотреть Здесь
не тычь мне википедией. википедию пишут обезьяны.
С каких пор оно из него пропало?
ну хорошо, не пропало, а весьма малоупотребительно. И уж во всяком случае, к неграмотной кальке с time zone оно не имеет отношения.
 

Observer

Новичок
pdi

TIMESTAMP не предназначен для хранения пользовательских данных. И точка.
Если это не так - аргументируйте.
 

pdi

Новичок
Автор оригинала: Фанат
ну, расскажи мне, родной, для каких целей оно может применяться, таких, с которыми бы не справились другие, предназначенные для этого типы.
Автоматическая конвертация из одного ЧАСОВОГО ПОЯСА в другой, автоматическая установка времени вставки записи (DATETIME не имеет такого значения по умолчанию, хотя поправимо = NOW(), но факт остается фактом).

Автор оригинала: Фанат
не тычь мне википедией. википедию пишут обезьяны.
Да не ужели?! Если ты не согласен с некоторыми высказываниями, это еще ничего не значит.

Автор оригинала: Фанат
ну хорошо, не пропало, а весьма малоупотребительно. И уж во всяком случае, к неграмотной кальке с time zone оно не имеет отношения.
Как time zone не назови... Ну да ладно...
ЗЫ. К названию топика тоже имеет отношение

<b>Observer</b>
А что подразумевается под пользовательскими данными? IMHO, для разработчика любое поле пользовательское, вроде как СУБД не создает системные поля, к которым конечный пользователь не имеет доступ и не может менять.
 

Фанат

oncle terrible
Команда форума
автоматическая установка времени вставки записи
постарайся не путаться в обсуждении и в своих собственных словах.
ты говорил о неких "других целях". отличных от автоматической установки.
Автоматическая конвертация из одного ЧАСОВОГО ПОЯСА в другой
поподробнее, пожалуйста.
 

Observer

Новичок
Автор оригинала: pdi
А что подразумевается под пользовательскими данными? IMHO, для разработчика любое поле пользовательское, вроде как СУБД не создает системные поля, к которым конечный пользователь не имеет доступ и не может менять.
Из того, что при желании можно менять данные непосредственно в БД 'mysql', не следует, что можно хранить там свой дневник. Мысль понятна?

Только для времени вставки/обновления стоит применять TIMESTAMP, остальное подпадает под категорию "нецелевое использование" с извращениями, чтобы заставить его работать так, как тебе хочется. Применяя его, нужно помнить о куче нюансов и разнице в версиях. Не думаю, что это нужно micolo сейчас.

Я понимаю, иногда хочется блеснуть познаниями... только надо сначала подумать, уместно ли это в данном случае.
 

pdi

Новичок
Автор оригинала: Фанат
постарайся не путаться в обсуждении и в своих собственных словах.
ты говорил о неких "других целях". отличных от автоматической установки.
Имеется ввиду, при insert, а не при update.

поподробнее, пожалуйста.
PHP:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 66 to server version: 5.0.16-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use `test`;
Database changed
mysql> CREATE TABLE `time` (
    -> `id` INT(4) NOT NULL AUTO_INCREMENT,
    -> `create_timestamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    -> `datetime` DATETIME NOT NULL,
    -> `some_data` INT(4) NOT NULL,
    -> PRIMARY KEY (`id`)
    -> ) ENGINE = MYISAM;
Query OK, 0 rows affected (0,04 sec)

mysql> INSERT INTO `time` SET `some_data` = 10; -- автоматическая установка `create_timestamp`
Query OK, 1 row affected, 1 warning (0,00 sec)

mysql> SELECT * FROM `time`;
+----+---------------------+---------------------+-----------+
| id | create_timestamp    | datetime            | some_data |
+----+---------------------+---------------------+-----------+
|  1 | 2006-10-17 13:50:14 | 0000-00-00 00:00:00 |        10 |
+----+---------------------+---------------------+-----------+
1 row in set (0,01 sec)

mysql> UPDATE `time` SET `datetime` = NOW(); -- `create_timestamp` не изменяется
Query OK, 1 row affected (0,00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> SELECT * FROM `time`;
+----+---------------------+---------------------+-----------+
| id | create_timestamp    | datetime            | some_data |
+----+---------------------+---------------------+-----------+
|  1 | 2006-10-17 13:50:14 | 2006-10-17 13:50:44 |        10 |
+----+---------------------+---------------------+-----------+
1 row in set (0,00 sec)

mysql> SHOW VARIABLES like 'time_zone'; -- все это дело происходит в системном часовом поясе 
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| time_zone     | SYSTEM |
+---------------+--------+
1 row in set (0,00 sec)

mysql> SHOW VARIABLES like 'system_time_zone'; -- т.е. Москва
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| system_time_zone | MSD   |
+------------------+-------+
1 row in set (0,00 sec)

mysql> SET time_zone = 'Europe/Samara'; -- сменим часовой пояс на Самару
Query OK, 0 rows affected (0,00 sec)

mysql> SELECT * FROM `time`;
+----+---------------------+---------------------+-----------+
| id | create_timestamp    | datetime            | some_data |
+----+---------------------+---------------------+-----------+
|  1 | 2006-10-17 14:50:14 | 2006-10-17 13:50:44 |        10 |
+----+---------------------+---------------------+-----------+
1 row in set (0,00 sec)
Как видно, timestamp показывает самарское время, datetime оставил московское.

-~{}~ 17.10.06 14:24:

Автор оригинала: Observer
Я понимаю, иногда хочется блеснуть познаниями... только надо сначала подумать, уместно ли это в данном случае.
Почему же, я просто опроверг Ваше высказывание:

Автор оригинала: Observer
Проблемы будут, когда ты решишь что-то поменять в записи. Поле с типом TIMESTAMP примет значение текущего времени.
Которое не всегда верно.

А по поводу извращений... Куда большим извращением бывает вытаскивать время на клиент и производить с ним преобразования, которые вполне бы могла сделать СУБД.

Возможно и не нужно, но, как говорится, "кто предупрежден - тот вооружен".
 

Observer

Новичок
Автор оригинала: pdi
Почему же, я просто опроверг Ваше высказывание:
Которое не всегда верно.
Я просто не стала вдаваться в подробности, которые только затемняют смысл.

А по поводу извращений... Куда большим извращением бывает вытаскивать время на клиент и производить с ним преобразования, которые вполне бы могла сделать СУБД.
Время в поле TIMESTAMP считается системным (опять это слово), поэтому делается соответствующая 'поправка' при извлечении.
Те манипуляции, которые Вы привели, мне кажется, вообще ни к чему. В поле для хранения времени надо помещать то время, которое на сайте считается текущим. Если часовые пояса сервера, на котором крутится пхп, и сервера БД различаются, то после соединения надо указать свой часовой пояс - и все даты, как указанные явно, так и получаемые через функции типа NOW() будут подставляться правильно.

А те манипуляции, что обычно делаются для того, чтобы посетителю показывалось его время (а не время сервера) лучше делать средствами пхп, не вижу в этом ничего зазорного. Если делать это средствами СУБД, то ухудшаются абстракция и переносимость.
 

Goblinid

Новичок
Автор оригинала: Observer
А те манипуляции, что обычно делаются для того, чтобы посетителю показывалось его время (а не время сервера) лучше делать средствами пхп, не вижу в этом ничего зазорного. Если делать это средствами СУБД, то ухудшаются абстракция и переносимость.
Вот-вот... про это подрбонее можно?
А то как раз встала задача обработать дату из базы. которая туда записана в Datetime то етьс грубо говоря прибавить к ней определенное количество часов что бы пользователю на сайте отражалась дата и время в его часовом поясе...

Или хотя бы направье меня куда надо.... в какую доку лезть?
 

Observer

Новичок
Автор оригинала: Goblinid
Вот-вот... про это подрбонее можно?
А то как раз встала задача обработать дату из базы. которая туда записана в Datetime то етьс грубо говоря прибавить к ней определенное количество часов что бы пользователю на сайте отражалась дата и время в его часовом поясе...

Или хотя бы направье меня куда надо.... в какую доку лезть?
Date and Time Functions

Ну положим, вам известен часовой пояс пользователя.

$tz - часовый пояс пользователя (в часах)
$time - время в юникс-формате, полученное из БД через UNIX_TIMESTAMP()

время для вывода пользователю = gmdate('d.m.Y H:i', $time + $tz*3600))

Необходимо правильно установить свой часовой пояс (через директиву date.timezone в php.ini или через функцию date_default_timezone_set)
 
Сверху