Форум MySQL

Эта штука выводит юзеров за последние сутки...

$sql = 'SELECT 'username', 'user_id' FROM 'users' WHERE 'user_lastvisit' > UNIX_TIMESTAMP(NOW() - INTERVAL 1 DAY)

...подскажите пожалуйста как седалть запрос который выводил бы юзеров посетивших за сегодня, а не за последние 24ч.

Зарание спасибо.

Можно поступить следующим образом

SELECT username, user_id FROM users WHERE user_lastvisit > '".date("Y-m-d 0:00:00")."'"

'SELECT 'username', 'user_id' FROM 'users' WHERE 'user_lastvisit' > UNIX_TIMESTAMP('.date("Y-m-d 0:00:00").'); ';

'SELECT 'username', 'user_id' FROM 'users' WHERE 'user_lastvisit' > '.date("Y-m-d 0:00:00").' ; ';

Что так что так... ничего не выводит... может дело в том что user_lastvisit хранится в поле INT(12) а не DATETIME...

Да дело в этом, лучше использовать DATETIME, если у вас имеются даты в UNIX TIMESTAMP их можно преобразовать в формат MySQL при помощи встроенной MySQL-функции FROM_UNIXTIME()

INSERT INTO tbl VALUES (NULL, FROM_UNIXTIME($timestamp))

Чем DATETIME лучше TIMESTAMP?
Ладно б где в другом контексте, но для lastvisit, по-моему, выбор DATETIME всяко противоестественный.

>Чем DATETIME лучше TIMESTAMP?
Дело в том, что начиная с MySQL 4.1 - внешне они ничем не отличаются и оба теперь хранятся в формате YYYY-MM-DD hh:mm:ss, т.е. TIMESTAMP теперь не хранится в секундах. Это связано с тем, что у TIMESTAMP имеется очень интересная особенность - такой столбец автоматически обновляется при выполнении операторов INSERT и UPDATE - на это часто не обращают внимание и используют его для хранения времени в UNIX TIMESTAMP - поэтому его формат приведён к DATETIME, чтобы заострить внимание на этой особенности.

Очень надеюсь что это не так.
Впрочем, сейчас проверю.

Как я и предполагал.
TIMESTAMP: Физически хранится в секундах. Например, 2006-05-29 13:45:11 (для таймзоны MSD) хранится как число секунд 1148895911. В файле лежит его двоичный вид: 447AC2A7

TIMESTAMP имеет соответствующие свойства, как то область определения и возможность установки в NOW(). Но не всегда, а лишь при необходимости.
SELECTом поле типа TIMESTAMP выводится в форме YYYY-MM-DD HH:MM:SS, что вобщем-то и удобно и оправданно.

DATETIME: Физически хранится в слабоупакованном виде, привязанном к таймзоне сервера:
Например, 2006-05-29 13:45:11 хранится как число 20060529134511 . В файле лежит его двоичный вид: 123EB4B68BAF

Физическое представление даты - это забота MySQL (собственно его менять не имело смысла - только ошибок в отлаженной код привнесли бы), для разработчика имеет значение только интерфейс. Если создадим таблицу

CREATE TABLE t ( date_time DATETIME NOT NULL , time_stamp TIMESTAMP NOT NULL  );

И поместим в неё запись

INSERT INTO t VALUES();

то выборка вернёт следующий результат

mysql> SELECT * FROM t; +---------------------+---------------------+ | date_time           | time_stamp          | +---------------------+---------------------+ | 0000-00-00 00:00:00 | 2006-05-29 17:34:31 | +---------------------+---------------------+

Т.е. формат типа TIMESTAMP, начиная с MySQL 4.1 действительно приведён к DATETIME (раньше вместо 2006-05-29 17:34:31 было бы целое число), а любой оператор UPDATE, даже не затрагивающий поле time_stamp - будет приводить к тому, что в этому полю будет автоматически присваиваться текущее время.

Ну и что ч того? Никто не мешает любое из этих двух свойств поля (инициализация текущим временем и автообновление текущим временем ) выключить. Как по одиночке, так и вместе.
Да, если не указывать явно умалчиваемое значение, то у первого TIMESTAMP-поля они окажутся включены. Но: а) если не указывать обратное, и б) только у первого из таких полей.

А разница между этими типами в первую очередь в том, что TIMESTAMP не связан локалью с сервером. Во вторую, в диапазоне представимых значений (мой день рождения, например, в формате TIMESTAMP переносимым образом не представить).
Если эти два момента (физический смысл и диапазон) несущественны для разработчика... что ж ... мне его жаль.

Согласен, все эти безумные навороты правил инициализации и автообновления от применения этого типа полей несколько отталкивают. Но это еще не повод заменять их на DATETIME скопом.

Это как с арбуза на дыню перейти. Вроде оба круглые и здоровые, и созревают оба в августе.
А вкус - разный.

Подсказали:

SELECT username, user_id  FROM users WHERE user_lastvisit > unix_timestamp( curdate( ) )