Кто в каком виде хранит дату в мускуле?

[samdark]

Причём строка эта зависит от timezone на сервере.

[zelenin]

Под меньше преобразований я имел ввиду случай с часовыми поясами (у меня они в каждом проекте) и тот факт, что timestamp при выборке из базы прилетает в PHP строкой и из PHP улетает тоже строкой.

правильно я понимаю, что в качестве аргумента за int в mysql, выступает обработка даты на стороне php? то есть отсутствие единого сервиса из одной строчки для нормализации даты для хранения в mysql является доводом за правильность хранения в int?
Ок, Александр, наверное вы правы. Зря в mysql поддерживают типы данных, связанных с датами. Оверхед лишний...

Чем всё-таки timestamp лучше и лучше ли чем int?

отбой! выяснили! дату храни числами, а строки сжатыми бинарниками - так меньше занимает!

[andrei.obuhovski]

Холивар точно int vs timestamp ? Или все таки timestamp vs datetime?

Как по мне так timestamp само норм. И выглядит нормально и временную зону меняет.



После команды SET time_zone = "+00:00";

[ElisDN]

Если в PHP нужно зону считать, то int. А если в базе, то timestamp.

[samdark]

правильно я понимаю, что в качестве аргумента за int в mysql, выступает обработка даты на стороне php?

Нет. Я сказал именно то, что сказал. Не надо переиначивать. Ну не хочу я делать каждый раз установку TZ на стороне базы.

[zelenin]

правильно я понимаю, что в качестве аргумента за int в mysql, выступает обработка даты на стороне php?

Нет. Я сказал именно то, что сказал. Не надо переиначивать. Ну не хочу я делать каждый раз установку TZ на стороне базы.

где же я переиначиваю?

Чем всё-таки timestamp лучше и лучше ли чем int?

не хочу я делать каждый раз установку TZ на стороне базы

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

[samdark]

Хватит уже спорить ради спора. Тем более, хлеб нисколько не тождественен хранению времени. Как аргумент аналогия не принимается

где же я переиначиваю?

"Потому что меньше преобразований и отсутствует возможность ошибиться с часовыми поясами." каким-то образом превратился в "правильно я понимаю, что в качестве аргумента за int в mysql, выступает обработка даты на стороне php?".

[samdark]

Плюсы int-а:

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

Минусы int-а:

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

[zelenin]

Хватит уже спорить ради спора. Тем более, хлеб нисколько не тождественен хранению времени. Как аргумент аналогия не принимается

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

[zelenin]

"Потому что меньше преобразований и отсутствует возможность ошибиться с часовыми поясами." каким-то образом превратился в "правильно я понимаю, что в качестве аргумента за int в mysql, выступает обработка даты на стороне php?".

да нет, как раз вы переиначили. "как правильно хранить время в mysql" превратилось в "как удобнее обрабатывать время в php".
Я уже не говорю о том, что ошибки в пхп со временем являются отсутствием системно-архитектурного подхода ко времени в проекте, где это важно.

[samdark]

Так почему правильно хранить во "времени", а не в числах? Что именно, помимо минусов выше строго запрещает использовать int-ы, объявляя их неправильными?

Кстати, чёрствый хлеб считается более полезным, чем свежий и широко применяется в кулинарии. Да и лень — это как раз есть свежий потому что усилий прилагается для его разжёвывания меньше. Так что аналогия действительно плохая.

"как правильно хранить время в mysql" превратилось в "как удобнее обрабатывать время в php".

Так мы работаем с PHP. Драйвер для MySQL вполне определённый и работает определённым образом. Мы тут не о философии выбра типа в MySQL в полном отрыве от реальности спорим.

[Nerf]

Плюсы int-а:
...
- Никак не привязан к часовым поясам. Идеален, если у каждого пользователя свой часовой пояс.

Не совсем. Если вы преобразовываете входные от пользователей даты, то там есть зависимость от часового пояса.

Код: Выделить всё

$date = '2016-04-21 12:00:00';
date_default_timezone_set('Pacific/Midway');
echo strtotime($date); // 1461279600
echo PHP_EOL;
date_default_timezone_set('Europe/Moscow');
echo strtotime($date); // 1461225600  

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

[zelenin]

Отчасти согласен с вами, преобразований строка-число-строка будет меньше.

при использовании datetime на какой стадии должно быть преобразование в int?

[Nerf]

Отчасти согласен с вами, преобразований строка-число-строка будет меньше.

при использовании datetime на какой стадии должно быть преобразование в int?

Код: Выделить всё

$inputDate = '21.04.2016';
$timestamp = strtotime($inputDate);
$mysqlStoreDate = date('Y-m-d H:i:s', $timestamp); 

ПС: через Datetime будет то же самое.

[zelenin]

Отчасти согласен с вами, преобразований строка-число-строка будет меньше.

при использовании datetime на какой стадии должно быть преобразование в int?

Код: Выделить всё

$inputDate = '21.04.2016';
$timestamp = strtotime($inputDate);
$mysqlStoreDate = date('Y-m-d H:i:s', $timestamp);

ПС: через Datetime будет то же самое.

DateTime::createFromFormat('d.m.Y', $inputDate);
DateTime полностью покрывает все потребности работы со временем, а strtotime является устаревшим и не рекомендуемым к использованию.

[Nerf]

DateTime::createFromFormat('d.m.Y', $inputDate);
DateTime полностью покрывает все потребности работы со временем, а strtotime является устаревшим и не рекомендуемым к использованию.

А что изменилось? Вы конвертируете строку в объект пхп, потом будете конвертировать в строку для mysql. Я же сказал "через Datetime будет то же самое". Да, не int, если вы об этом .

[zelenin]

DateTime::createFromFormat('d.m.Y', $inputDate);
DateTime полностью покрывает все потребности работы со временем, а strtotime является устаревшим и не рекомендуемым к использованию.

А что изменилось? Вы конвертируете строку в объект пхп, потом будете конвертировать в строку для mysql. Я же сказал "через Datetime будет то же самое". Да, не int, если вы об этом .

это верно. поэтому аргумент про преобразования отбрасываем.

[R3D3]

Холивар точно int vs timestamp ? Или все таки timestamp vs datetime?

В этом холиваре нету смысла, у datetime есть вполне четкое преимущество перед timestamp - оно умеет хранить даты до 1 января 1970 года. Timestamp не умеет, но хорошо годится для хранения отметок времени когда запись создали, когда обновили и т.д., то есть события, которые происходили не далеко в прошлом, а происходят прямо сейчас в процессе работы приложения.

[Dromok]

посмотрите на автора - он пришел спросить мнения, а в итоге скатился в защиту своей позиции.

Эээ... вообще-то я как раз в результате обсуждений в этой теме перешел на timestamp с int и чётко об этом написал (по крайней мере в новом проекте попробую с ним поработать). Datetime я даже не рассматривал, о чем изначально и написал. Выбор был между int и timestamp.
Timestamp к слову поддерживает все теже функции что и Datetime и визуально в базе отображается точно также, но занимает в два раза меньше места.
Короче если не нужны даты раньше 1970 года, то timestamp предпочтительнее чем datetime. Но повторюсь, я datetime даже не рассматривал и в вопросе его упоминания не было.

Минусы int-а:
- На 32-битных системав в 2038 году будет переполнение.

Если поставить полю атрибут UNSIGNED, то дата в int может храниться до 2106 года даже на 32-битной системе. Так что этот минус можно выбросить.

А так да, пока что единственное что меня смущает в timestamp это то, что в случае неверной настройки таймзоны у мускула неверно будет возвращаться время. В общем попробую в новом проекте и если с timestamp не возникнет проблем, то буду везде его использовать.

[Nerf]

Если поставить полю атрибут UNSIGNED, то дата в int может храниться до 2106 года даже на 32-битной системе. Так что этот минус можно выбросить.

Вы сейчас второй холивар начнете))