Владимир М.
578 сообщений
#15 лет назад
Уважаемый ТС, все решается просто, без размышлений - в ТЗ пишется пункт №ХХХ.ZZZ - даты и время класть в TIMESTAMP. кто-то молча поставит галочку, кто-то скажет - я так и делаю, кто-то попросит прибавку к зарплате. но в целом - вы получите желаемое без оговорок. если спрашивают - зачем - говорите - надо (федя, надо).
---
имхо - ни разу не встречал чотбы кто-то сказал - "....а что й -то вы мне дату интом записали....?"
Фрилансер У.
248 сообщений
#15 лет назад
Цитата ("Lisio"):
Попробуйте вот этот код, где $var - время, которое получено из базы, если хранить его в timestamp
echo date('d.m.y', $var);

echo date('d.m.y',strtotime($var));
Андрей К.
1172 сообщения
#15 лет назад
werewolf, угу, -1 к производительности. И при записи обратно конвертировать. Еще -1.
Кирилл Е.
2817 сообщений
#15 лет назад
Юху.. холивар

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

..а если чел опытный и знает что такое TIMESTAMP - пусть в тз или устно просит хранить даты в нужном представлении во избежании создания подобных тем )

* Зачем платить (если платить) деньги за административную часть\админку, чтобы вручную в базе ковыряться?
Евгений О.
2989 сообщений
#15 лет назад
Цитата ("Lisio"):
угу, -1 к производительности. И при записи обратно конвертировать. Еще -1.

Вообще-то, насколько я знаю, еще никому не удалось измерить изменение производительности при манипуляциях с датой . Не нравиться ковертировать дату в PHP, конвертируйте в запросе.
Кстати дата/время храниться всегда в виде числа. Только формат числа разный при разных типах поля даты.
Фрилансер У.
248 сообщений
#15 лет назад
Цитата ("elosoft"):
конвертируйте в запросе

Если используется ORM/ActiveRecord конвертировать дату в запросах не очень-то хочется.
Цитата ("Lisio"):
-1 к производительности. И при записи обратно конвертировать. Еще -1.

На такие вещи не обращаю внимания. TIMESTAMP избавляет от date('Y-m-d H:i:s',$dt);, так что если формат не менять, получится даже быстрей.
Андрей К.
1172 сообщения
#15 лет назад
Цитата ("kirilev"):
* Зачем платить (если платить) деньги за административную часть\админку, чтобы вручную в базе ковыряться?

+1, про это я и написал на первой странице

Цитата ("werewolf"):
На такие вещи не обращаю внимания.

Как и большинство. Потом жалуются заказчики.
Фрилансер У.
248 сообщений
#15 лет назад
Цитата ("Lisio"):
Потом жалуются заказчики.

Не думаю что в типовом "движке" такая операция будет узким местом.
Андрей К.
1172 сообщения
#15 лет назад
Ага, так думали создатели Битрикса. Когда узким место является весь движок, то зачем думать о мелочах.
Евгений О.
2989 сообщений
#15 лет назад
Цитата ("werewolf"):
TIMESTAMP избавляет от date('Y-m-d H:i:s',$dt);, так что если формат не менять, получится даже быстрей.

А как Вы выкручиваетесь когда Вам требуется как основу использовать локальное время клиента сервера, а не по Гринвичу?

p.s. Преобразования типа date('d.m.y',strtotime($var)) можно легко обойти, если учесть, что тип datetime храниться в mysql в формате YYYYMMDDHHMMSS...
Фрилансер У.
248 сообщений
#15 лет назад
Цитата ("elosoft"):
А как Вы выкручиваетесь когда Вам требуется как основу использовать локальное время сервера, а не по Гринвичу?

Поставил бы часовой пояс сервера в настройках/при соединении, наверное так.
Я с таймштампом совсем немного работал.
Евгений О.
2989 сообщений
#15 лет назад
Цитата ("werewolf"):
Поставил бы часовой пояс сервера в настройках/при соединении, наверное так.

Можно и проще . Выбираем тип поля в таблице такой, который будет использоваться чаще всего без потребности в преобразовании. А в остальных случаях соответсвенно преобразуем.
И еще. Можно установить само преобразование в нужный формат непосредственно в свойствах поля таблицы. Получим сразу то, что нужно.