Как лучше хранить дату, чтобы с ней было удобно работать.

Just use ORM, Luke.

как ни храни. работать ты с ней будешь одинаково. Так что храни в datetime.

int

4байта, детчока пишет курсач который в 32 году уничтожит землю

так пишет видимо на java

Мне его не в 32м сдавать, а в пятницу.

используй sql.

просто хорошие привычки в области кодонаписания они либо прививаются сразу либо не прививаются потом вообще

Храни в Unix-time как long. Не используй SQL (используй no-SQL БД).

>который в 32 году уничтожит землю

в 38-м. хотя, чем Столлман не шутит.

MJD 55276.667975

>Так что храни в datetime.

Если объёмы большие, то быстро станет понятно, что DATETIME сильно медленнее INT'а. Особенно при выборках интервалов. (Индексы, как бы, подразумеваются, так что К.О. пусть спит)

int

4байта, детчока пишет курсач который в 32 году уничтожит землю

18 января 2038 можно сделать ALTER TABLE ... BIGINT ...

Если работать с историческими датами, то лучше всего вообще в юлианских днях время хранить...

>Если работать с историческими датами, то лучше всего вообще в юлианских днях время хранить...

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

детчока пишет курсач который в 32 году уничтожит землю

органы безопасносте пресекут распространение курсача

Ох, в 2038 году никто не будет даже знать, что такое alter table, тем более bigint

>Ох, в 2038 году никто не будет даже знать, что такое alter table, тем более bigint

Тогда и проблемы такой не будет ;)

>>int

4байта, детчока пишет курсач который в 32 году уничтожит землю

конец света в 2012, так что всё равно

timestamp

Я в базе храню unixtime в unsigned int

> Я в базе храню unixtime в unsigned int

А как насчет таймзоны? :-)

>Если работать с историческими датами, то лучше всего вообще в юлианских днях время хранить...

Да, а длину в локтях измерять.

Юлианские дни - общепризнанный способ измерения времени (в астрономии). Так что не надо про локти.