Datetime или timestamp

    На днях я столкнулся с тем, что многие разработчики не знают в чём отличие типов данных DATETIME и TIMESTAMP в MySQLе, а так же как хранить дату и время, если необходимо учитывать разные часовые пояса для разных пользователей веб-приложения. Поэтому хочу дать ниже разъяснения с пояснениями.

    DATETIME
    Хранит время в виде целого числа вида YYYYMMDDHHMMSS, используя для этого 8 байтов. Это время не зависит от временной зоны. Оно всегда отображается при выборке точно так же, как было сохранено, независимо от того какой часовой пояс установлен в MySQL. Даю пример:

    mysql> create table `dt1` ( col datetime NOT NULL );
    mysql> SET @@session.time_zone='+00:00';
    mysql> select now();
    +---------------------+
    | now() |
    +---------------------+
    | 2009-06-04 18:13:56 |
    +---------------------+

    mysql> insert into dt1 values(now());

    mysql> SET @@session.time_zone='+01:00';
    mysql> select now();
    +---------------------+
    | now() |
    +---------------------+
    | 2009-06-04 19:14:20 |
    +---------------------+

    mysql> insert into dt1 values(now());

    mysql> SET @@session.time_zone='+00:00';
    mysql> select * from dt1;
    +---------------------+
    | col |
    +---------------------+
    | 2009-06-04 18:14:10 |
    | 2009-06-04 19:14:27 |
    +---------------------+


    TIMESTAMP
    Хранит 4-байтное целое число, равное количеству секунд, прошедших с полуночи 1 января 1970 года по усреднённому времени Гринвича (т.е. нулевой часовой пояс, точка отсчёта часовых поясов). При получении из базы отображается с учётом часового пояса. Часовой пояс может быть задан в операционной системе, глобальных настройках MySQL или в конкретной сессии. Запомните, что сохраняется всегда количество секунд по UTC (универсальное координированное время, солнечное время на меридиане Гринвича), а не по локальному часовому поясу. Пример:

    mysql> create table tm1 (col timestamp not null);
    mysql> set @@session.time_zone = '+00:00';
    mysql> select now();
    +---------------------+
    | now() |
    +---------------------+
    | 2009-06-04 18:24:54 |
    +---------------------+
    mysql> insert into tm1 values(now());
    mysql> select * from tm1;
    +---------------------+
    | col |
    +---------------------+
    | 2009-06-04 18:25:08 |
    +---------------------+

    mysql> set @@session.time_zone = '+01:00';
    mysql> select now();
    +---------------------+
    | now() |
    +---------------------+
    | 2009-06-04 19:25:21 |
    +---------------------+
    mysql> insert into tm1 values(now());
    mysql> select * from tm1;
    +---------------------+
    | col |
    +---------------------+
    | 2009-06-04 19:25:08 |
    | 2009-06-04 19:25:26 |
    +---------------------+

    mysql> set @@session.time_zone = '+00:00';
    mysql> select * from tm1;
    +---------------------+
    | col |
    +---------------------+
    | 2009-06-04 18:25:08 |
    | 2009-06-04 18:25:26 |
    +---------------------+


    Ещё одно отличие! TIMESTAMP по умолчанию NOT NULL, а его значение по умолчанию равно NOW().

    mysql> insert into dt1 values(null);
    ERROR 1048 (23000): Column 'col' cannot be null
    mysql> insert into tm1 values(null);
    Query OK, 1 row affected (0.00 sec)
    mysql> select * from tm1;
    +---------------------+
    | col |
    +---------------------+
    | 2009-06-04 18:25:08 |
    | 2009-06-04 18:25:26 |
    | 2009-06-04 18:32:50 |
    +---------------------+


    Дополнение. Для тех, кого смущает использование функции NOW().

    mysql> set @@session.time_zone = '+00:00';
    mysql> insert into dt1 values('2009-06-04 22:00:00');
    mysql> set @@session.time_zone = '+01:00';
    mysql> select * from dt1;
    +---------------------+
    | col |
    +---------------------+
    | 2009-06-04 22:00:00 |
    +---------------------+

    mysql> set @@session.time_zone = '+00:00';
    mysql> insert into tm1 values('2009-06-04 22:00:00');
    mysql> set @@session.time_zone = '+01:00';
    mysql> select * from tm1;
    +---------------------+
    | col |
    +---------------------+
    | 2009-06-04 23:00:00 |
    +---------------------+
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 132
    • +6
      тока вы не путайте одно с другим. вы же записываете в базу значение NOW которое зависит от часового пояса :) конечно значение в базе будет изменяться. данные в базе статичны и не зависит ни от чего. что положили, то и достанете. а вот КАК и что вы туда положите это уже другой вопрос
      • 0
        Правильно. Я записываю в таблицу время текущего часового пояса. И в DATETIME оно сохранится именно для этого пояса и точно также будет отображаться в дальнейшем, независимо от того, какой часовой пояс вы укажете. TIMESTAMP же покажет сохранённые данные по-разному для разный часовых поясов. Я где-то неправ?
        • +1
          > по усреднённому времени Гринвича
          > Зависит от установленного часового пояса.
          Время по Гринвичу для того и создавалось, чтобы не зависеть от часового пояса.

          Тут понятие «зависимости» очень кривое…
          В DATETIME «нулём» выбран локальный пояс, в TIMESTAMP — более универсальный UTC. Поэтому TIMESTAMP менее зависим от установленного часового пояса.

          Определённые проблемы, кстати, вносит не только часовой пояс, но и летнее время…
          • 0
            Я бы даже сказал, что два раза в год возникают определённые проблемы.
        • +3
          Добавил для вас пример без функции NOW().
        • 0
          А что насчет сравнения скорости выборки по полям типа Timestamp и DateTime? Например выборка по поределенному месяцу, дню недели и т д. В каком случае будет работать быстрее?
          • 0
            по таймстепу быстрее. Но если строить индекс по datetime, то рекомендуется использовать force index. Особенно это касается при выборке данных по указанным промежуткам времени.
            • 0
              А мне казалось что по dateTime многие выборки должны идти быстрее. Ведь логично, что например выборка по номеру месяца из записи вида YYYYMMDDHHMMSS должна осуществляться МНОГО быстрее, чем по записи вида timestamp. В случае c timestamp, как я понимаю, приходится каждое поле преобразовывать в дату и только потом производить операцию сравнения условия.
              • 0
                нет, не быстрее, так как строка (dt) переводится в число (int) переводится какое-то время, когда ts — это уже число. Речь идет про ограниченные выборки, разумеется.
                • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            Еще полезная фича ON UPDATE CURRENT_TIMESTAMP, с datetime вроде не прокатит.
            • 0
              Было время намучался с етим CURRENT_TIMESTAMP и совсем запутался в часовых поясах, так как сервер был в штатах и имел необычную конфигурацию.
              Как указать часовой пояс сервера в php все понятно, а вот с базой данных пришлось изощьрятся с помощью CONVERT_TZ, DATE_ADD, DATE_SUB так как доступа к конфигурации БД не предусматривалось.
              Решил везде использовать DATETIME и дать возможность PHP самому указивать сколько времени.
              • 0
                Попробуйте так
                mysql_query(«SET LOCAL time_zone='+03:00'»);
                • 0
                  Это значение не учитывает переход на летнее время, если он есть.
                  Правильней — указывать название таймзоны («Europe/Kiev», «America/New_York» и т.п.)
            • 0
              дату всегда храню в datetime.
              во-первых читабельна
              во-вторых есть куча удобных функций для работы с полем в формате datetime

              ps. не знал что timestamp пересчитывается в соответствии с установленной временной зоной
              • 0
                Совершенно верно.
                У datetime свои вкустности и удобства есть, но по 8 байт :\
                Можно по 4, но без удобств :)
                • –1
                  А там по байту была, и вообще не дата, так и байта не было…
                • 0
                  timestamp выводится так же как и datetime в новых версиях mysql ('YYYY-MM-DD HH:MM:SS', точно в 5.0), в старых без пунктуации.
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      Я имею в виду вид, в котором значение возвращается при SELECTе.
                • НЛО прилетело и опубликовало эту надпись здесь
                  • –3
                    не проще ли хранить таймстемп в обычном int?
                    • +3
                      Это отличный пример как не надо делать.
                      • +4
                        побольше слов, пожалуйста (если они есть)
                        • +1
                          Пока Nc_Soft молчит, позволю себе ответить за него.

                          Тип данных INT предназначен для хранения целых чисел.
                          Типы данных DATETIME и TIMESTAMP предназначены для… в общем, я уверен, что вы поняли, к чему я веду.

                          Так вот, давайте поставим вопрос с головы обратно на ноги: если у вас (не лично у вас, а у всех удивившихся) есть какие-то аргументы за то, чтобы использовать какой-либо тип данных не по его прямому назначению, игнорируя другой тип данных, предназначеный именно для решения вашей задачи — лично мне будет интересно их выслушать.
                          • +1
                            Зря парня минусуете. Абсолютно правильно говорит. Хранить TIMESTAMP в INT это все-равно что в С (или паскале, или еще каком-нибудь языке программирования, кому как больше нравится) заводить переменную int вместо bool. Если в int сохранять 0 и 1, эффект будет абсолютно идентичный, но читабельность кода ухудшается. Ухудшается читабельность — увеличивается вероятность появления ошибки.
                            • 0
                              В C нет типа bool, поэтому используется именно int ;)
                              Но это так, к слову)
                          • +3
                            А почему INT? Давайте в VARCHAR или TEXT хранить дату, чего уж там…
                            Использовать для даты надо типы для даты, иначе вы потеряете кучу возможностей и простые операции, которые можно сделать в sql придется реализовывать уже средствами php.
                            • –4
                              По-моему проще сделать на php, чем заставлять делать это mysql.
                              Если у вас большой цикл, то проще сначала объявить переменную в php до цикла, а потом подставлять в запрос, чем каждый раз в запросе писать NOW()
                              • +2
                                Sql запросы в цикле лучше стараться не делать.
                                И вообще, не понимаю почему некоторые пытаются убедить, что забивать гвозди лопатой лучше, чем молотком.
                                Ну никакого преимущества нет у int по сравнению с timestamp в хранении даты.
                                Возьмем банальнейший пример: регистрация пользователя. Если тип int запрос будет какой-то такой
                                «INSERT INTO reg SET login='$login', pass=MD5('$pass'), reg_time='».time()."' "
                                Если поле reg_time имеет тип timestamp и по дефаулту у него стоит CURRENT_TIMESTAMP, то запрос будет уже такой
                                «INSERT INTO reg SET login='$login', pass=MD5('$pass') „
                                reg_time заполнится автоматически текущим временем.
                                Уже 1:0 в пользу timestamp :)
                                • –3
                                  Про SQL запросы в цикле: если нужно сделать, значит нужно. Как вы предлагаете например вставить в таблицу 10000 записей?

                                  А если мне нужно чтобы в поле reg_time был не текущий timestamp, а + один день?
                                  $tomorrow = date('Y-m-d H:i:s', (time()+86400));

                                  И на счёт MD5 не согласен. Лучше возложить это на php.

                                  «INSERT INTO reg SET login='$login', pass='».md5($pass)."', reg_time='$tomorrow' "
                                  • 0
                                    >> Как вы предлагаете например вставить в таблицу 10000 записей?
                                    Рекомендую так (примерно, я не знаю php):

                                    INSERT INTO table (col1,col2) VALUES
                                    for ($i=1; $i<=10000; $i++)
                                    {
                                    (...тут значения столбцов...)
                                    }[, ]


                                    Так не получится в одном случае — если вы вставляете достаточно большие значения и суммарный запрос превысит лимит размера запроса, установленный на сервере (по умолчанию 1Mb, если мне память не изменяет).

                                    Делать 10000 инсертов в такой ситуации — это очень неоптимально.

                                    >> А если мне нужно чтобы в поле reg_time был не текущий timestamp, а + один день?
                                    У mysql полно функций, работающих с датами, практически всегда можно найти нужную под задачу.

                                    >> И на счёт MD5 не согласен. Лучше возложить это на php.
                                    Вы хоть какие то доводы привели бы. Почему лучше? Потому что лично вам так нравится больше? Или потому что вы просто возможности mysql знаете гораздо меньше, чем возможности php?

                                    • –2
                                      На счет первого: согласен можно сделать так.
                                      На счет второго и третьего: как то мы вставляли данные в MySQL, но предварительно нужно было вычислить экспоненты, логарифмы и прочую нечесть и сделали сначала с помощью MySQL. Сервак начал жутко тормозить. Потом перенесли эти расчеты на php, и всё стало намного быстрее.

                                      Например у нас mysql сервер выделенный, и он очень загружен, а php сервер достаточно свободный, поэтому в данном случае вычислять лучше на php. Он это сделает быстрее
                                    • 0
                                      INSERT INTO reg SET login='$login', pass=MD5('$pass'), reg_time=NOW() + INTERVAL 1 DAY
                                      Про инсерт в 10000 записей опять же можно сделать дефаултное значение и даже NOW() писать не придется, а используя int вы не можете сделать дефаултное значение текущей метки времени, это уже булыжник в огороде.
                                      • 0
                                        Как вставить 1000 записей в базу
                                        Синтаксис оператора INSERT
                                        INSERT [LOW_PRIORITY | DELAYED] [IGNORE]
                                        [INTO] tbl_name [(col_name,...)]
                                        VALUES (expression,...),(...),…

                                        Обратите внимание на последнюю строчку.

                                        Запросов в цикле — не должно быть.
                                    • 0
                                      Однажды один умный человек мне сказал.
                                      — Нет смысла перекладывать обязаннсоти сервера БД на web сервер.
                                      Во-первых ему и так работы хватает.
                                      Во-вторых сервер бд заточен для подобных операций, он куда лцчше это сделает.
                                    • +1
                                      int — удобно для портирования базы в другую СУБД, в которой может отсутствовать timestamp.
                                      • 0
                                        Дак можно, наверное, как-нибудь переконвертить тип поля перед портированием?
                                        ALTER TABLE что-то там…
                                        Или с timestamp не получится?
                                        • 0
                                          думаю можно, но суть то как раз в том, чтобы избежать этих самых ALTER-ов ;)
                                        • 0
                                          А часто ли происходит данная «портация данных»? Да и будет ли самой большой проблемой именно портация таймстампта?

                                          Имхо жертвовать повседневной удобностью ради сохранения десяти минут при операции которая проводица достаточно долго, тягостно и проблематично и без этого — феерический бред.
                                        • 0
                                          То есть других резонов, кроме «так надо» нет?
                                          • 0
                                            А аргументы за то, чтоб делать через одно место есть?
                                            • 0
                                              А глаза есть? Я ещё вчера написал аргументы
                                              Если использовать таймстемп то как раз и выйдет через одно место
                                              • 0
                                                Если только в другом топике. Тут по вашему нику ничего не находится.
                                            • 0
                                              Наличие встроенных функций для работы с timestamp?
                                              • 0
                                                Ок.
                                                Мне нужно выбрать все записи, в котором поле lastLogin не старше 01-05-2009. Как будет выглядеть запрос в случае timestamp?
                                                • –1
                                                  select * from tbl WHERE lastLogin < '01-05-2009'
                                                  • +1
                                                    Тоесть вот так конечно же
                                                    select * from tbl WHERE lastLogin < '2009-05-01'
                                                    • 0
                                                      и оно будет работать быстрее, чем

                                                      select * from tbl WHERE lastLogin < 1241136000 (в случае инта)?
                                                      • 0
                                                        Тут надо тесты проводить по хорошему. Я думаю, что запросы будут одинаковыми по скорости, если оптимизатор mysql просечет фишку и сконвертирует дату 2009-05-01 в число, а потом будет делать выборку на основе сравнения чисел.
                                                        • 0
                                                          А какая разница? У вас уже в конкретной задаче скорости не хватает? Мне кажется, решение с таймстампом лучше, потому что:
                                                          1. лучше читается.
                                                          2. удобнее в использовании.

                                                          Если начинает не хватать скорости, то переконвертить в инт действительно может быть одним из способов оптимизации (если быстрее, конечно).
                                                          • 0
                                                            Вопрос на засыпку: вы уверены, что mysql переведет дату в число 1241136000 быстрее чем язык из которого вы формируете SQL-запрос?

                                                            ВИН.
                                                            • 0
                                                              я уверен, что читать внимательнее надо, что пишут в посте: mysql хранит таймстемп в интах

                                                              ЭПИК ФЕЙЛ
                                                              • 0
                                                                Ну, собственно, если проследить за логикой диалога, то можно понять что я примерно того же мнения :) просто описался в конкретном сообщении :)

                                                                Таки ВИН :)
                                                        • 0
                                                          select * from tbl WHERE lastLogin < Unix_timestamp('01-05-2009')
                                                          • 0
                                                            и оно будет работать быстрее, чем

                                                            select * from tbl WHERE lastLogin < 1241136000 (в случае инта)?
                                                            • 0
                                                              разумеется нет. но да, если потребуется сделать выборки за промежутки времени. кроме того — читабельность и соответствие типа данных — хранимым данным.
                                                            • +1
                                                              Зачем здесь функция Unix_timestamp(), если поле типа timestamp? Этот запрос ничего не найдет вообще.
                                                              • 0
                                                                слева таймстемп — справа строка, приведенная к таймстемпу с помощью функции.
                                                                • +1
                                                                  Почему вы считаете, что unix_timestamp и тип данных mysql timestamp — это одно и тоже? Это не так. TIMESTAMP — это специальный подвид типа DATETIME!!! Я ниже более подробно описал различия.

                                                                  Если не верите мне, проверьте сами, ваш запрос не работает, потому что слева — дата, а справа число.
                                                            • 0
                                                              перед тем как мучать DB нужно ответить на вопрос «что такое „01-05-2009“»?
                                                        • 0
                                                          Знаю одну довольно известную вебдизайнерскую контору, где так и делают. :)
                                                          • 0
                                                            простые операции, которые можно сделать в sql придется реализовывать уже средствами php

                                                            яркий пример устоявшихся связей и шаблонности человеческого мышления. ведь кроме php есть куча других языков, но почти всегда вспоминают шаблон mysql+php :D
                                                            • 0
                                                              Как раз на днях столкнулся с реальным индусским кодом, где timestamp хранился в поле типа TEXT :)
                                                          • +1
                                                            ага, это почему это?
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                              • +4
                                                                Есть достаточное количество удобных функций для работы с датами (http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html).
                                                                Например:
                                                                     SELECT DATE_ADD(created_at, INTERVAL 1 MONTH) FROM…
                                                                С полем типа INT они работать не будут, с DATETIME/TIMESTAMP будут.
                                                                Кроме того обычный SELECT преобразует вам DATETIME/TIMESTAMP в читабельный вид.
                                                              • +1
                                                                Храню дату в BIGINT потому как работаю с JAVA — а там дата фактически хранится в миллисекундах от определенного момента времени.

                                                                Проблем ни с индексами, ни с запросами не испытываю — потому как при запросах с WHERE < > дата с которой происходит сравнение автоматически конвертируетсяв BIGINT.

                                                                Функции DATE_ADD и прочие мне не нужны — потому как у меня апп-сервер и все происходит на нем. Учет клиентской таймзоны — тоже на апп-сервере.

                                                                На крайний случай, когда надо глазами в консоли посмотреть чего записано, использую FROM_UNIXTIME(date/1000)
                                                              • 0
                                                                как было подмечено выше «timestamp выводится так же как и datetime в новых версиях mysql ('YYYY-MM-DD HH:MM:SS', точно в 5.0), в старых без пунктуации.»

                                                                т.е. к int-у это не сработает. а в остальном не вижу различий между int и timestamp
                                                                • 0
                                                                  то есть если мне надо банально узнать в похапе разницу в секундах между двумя таймстемпами, мне надо 'YYYY-MM-DD HH:MM:SS' конвертировать в int?
                                                                  • 0
                                                                    я говорил про timestamp vs int.

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

                                                                    думаю плюсы datetime в виде функций ADDDATE,YEARWEEK,CONVERT_TZ… все таки перевешивают плюсы timestamp-а
                                                                    • +1
                                                                      А как же ADDTIME(FROM_UNIXTIME(`unix_timestamp`))? :)
                                                                      • 0
                                                                        при таком варианте индекс не получится использовать. mysql-ю придется конвертить каждое значение для обработки запроса
                                                                        • +2
                                                                          Бррр… я окончательно запутался в том, кто про что пишет, потому в предыдущем комментарии написал вообще нечто, никак не связанное с вашими словами выше. Произвожу корректировку :)

                                                                          Вы написали следующее (на что я вам ответил про вариант с int, что не к селу ни к городу)

                                                                          >> думаю плюсы datetime в виде функций ADDDATE,YEARWEEK,CONVERT_TZ… все таки перевешивают плюсы timestamp-а

                                                                          Ответ — неверно. TIMESTAMP — это тоже временной тип данных, поэтому все функции применимые к DATETIME применимы и к TIMESTAMP. Разница лишь в методе хранения этих типов — DATETIME хранится в виде числа! YYYYMMDDHHMMSS, а TIMESTAMP в виде количества секунд с Epoch. Не считая еще описанной в топике разницы с TZ, того, что timestamp не может быть null, и фич с автоапдейтом, с точки зрения программиста они одинаковы. Но внутренее хранение накладывает еще и свои различия — DT больше TS в два раза, зато позволяет записывать даты произвольные, а не с 70 по 38 год.

                                                                          И всё таки про индексы тоже скажу. Раз вы про них упомянули, значит речь идет об использовании этих функций в WHERE (или join, что тоже самое). Скажите, почему вы решили, что например

                                                                          .... WHERE YEARWEEK(FROM_UNIXTIMESTAMP(`unixtime`)) = 200922 ...

                                                                          не будет использовать индексы, а

                                                                          .... WHERE YEARWEEK(`datetime`) = 200922 ...

                                                                          — будет? Индекс не будет работать в обоих случаях
                                                                      • +2
                                                                        а я про них и спрашивал

                                                                        вот у меня есть какое-нибудь событие, например пользователь входит в систему — login. я хочу сделать запись в базу о том, когда это случилось. функция time мне возвращает int. я его в неизменном виде отражаю в базе, как mysql int. когда мне нужно показать пользователю (или админу) дату его последнего захода, то я возьму этот int из базы и с помошью date преобразую и покажу в нужном формате — верно?

                                                                        какие преимущества может дать мне в этом случае mysql timestamp?
                                                                        • 0
                                                                          разве timestamp это не int?
                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                            • 0
                                                                              разве он при селекте вернёт инт?
                                                                              судя по примерам выше — нет
                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                • 0
                                                                                  правильно ли я понимаю, что поле timestamp задумано как сервисное поле к записи и проставляется самой базой автоматически?
                                                                                • 0
                                                                                  должен вернуть int. или вернет строку в языках со строгой типизацией?
                                                                            • +2
                                                                              > как часто вам приходится работать с датами в виде целого числа?
                                                                              Мне с ними приходится работать каждый раз, когда в шаблоне надо cделать strftime… То есть, собственно, мне только в таком виде с датами и приходится работать, за реееедким исключением.
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                              • –2
                                                                                ага…
                                                                                SELECT UNIX_TIMESTAMP(lastLogin) FROM…

                                                                                но с intом-то проще )
                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                        • +1
                                                                          timestamp может обновляться сам при апдэйте данных (ON UPDATE CURRENT_TIMESTAMP) и такое поле может быть только одно в таблице
                                                                          • +3
                                                                            если TIMESTAMP полей несколько, автоматом обновляется, только, первое
                                                                            • 0
                                                                              при одном из условий:

                                                                              • 0
                                                                                Столбец не указан явно в команде INSERT или LOAD DATA INFILE.

                                                                                Столбец не указан явно в команде UPDATE, и при этом изменяется величина в некотором другом столбце (следует отметить, что команда UPDATE, устанавливающая столбец в то же самое значение, которое было до выполнения команды, не вызовет обновления столбца TIMESTAMP, поскольку в целях повышения производительности MySQL игнорирует подобные обновления при установке столбца в его текущее значение).

                                                                                Величина в столбце TIMESTAMP явно установлена в NULL.
                                                                          • –10
                                                                            Простите, но для пользователя PostgreSQL данный топик кажется дикостью.
                                                                            • +6
                                                                              Но ведь топик находится в блоге MySQL, не так ли? Так какого х.., кхм, простите, зачем вы это здесь написали?

                                                                              Ну а раз уж зашли — может расскажете почему вам кажется дикостью данный топик, просветите окружающих?
                                                                            • 0
                                                                              я так понимаю, что TIMESTAMP в определенный момент даст сбой (так как 4х байтное число INT конечно)?
                                                                              • 0
                                                                                В 38-м году, если не ошибаюсь.
                                                                                • 0
                                                                                  • +1
                                                                                    Хе-хе, ну и красавцы, пишут и даже без смайлов:

                                                                                    Введение 64-битного формата вносит новую дату «закольцевания» через примерно 290 миллиардов лет, в 15:30:08 UTC в воскресенье, 4 декабря 292 277 026 596 года. Но данная проблема, в принципе, срочной не считается.

                                                                                    Еще бы ее срочной считать )))
                                                                                    • +1
                                                                                      Без смайликов юмор не воспринимается?
                                                                                      • 0
                                                                                        Думаете в ситкомах на заднем плане для чего смеются?
                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                          • 0
                                                                                            Так получилось. я не знал, что топик старый. Читал главную, одновременно искал по хабру.

                                                                                            Простите меня, я так больше не буду…
                                                                              • 0
                                                                                Есть мысть, не помню кем высказанная, что метки времени нужно хранить в виде timestamp. Ну к примеру когда пользователь залогинился, или метки для подсчета кол-ва пользователей на сайте.

                                                                                Дату рождения же соит хранить в виде DateTime.

                                                                                Мысть не моя. Насколько она верна — думайте сами.
                                                                                • +2
                                                                                  дату рождения я думаю можно и в DATE хранить
                                                                                • –1
                                                                                  Еще один прочитал маны… Давайте тогда будем писать статьи о том, чем в php echo от print отличается? Если разработчик не знает в чем разница между datetime и timestamp, то это не разработчик, а полуграмотный недоучка, которому лень было основные разделы документации прочитать.
                                                                                  • 0
                                                                                    Зря вы так. Покажите мне разработчиков, которые прочитали всю официальную документацию по MySQL. А я описал случай, с которым столкнулся на практике.
                                                                                    • +1
                                                                                      это вопрос все-же не про MySQL
                                                                                      это общий вопрос по информатике
                                                                                      поддерживаю Psoxozzz, не смотря на ник
                                                                                      недоразработчики — это зло и для клиентов, и для нормальных ребят
                                                                                      • +1
                                                                                        Нет, не зря. Я не спорю, что вы столкнулись с этим на практике. К сожалению, в наше время много начинающих людей, которые, нахватавшись вершков, считают себя профессионалами. Я поясню категоричность своего предыдущего комментария. В любом проекте сложнее двухстраничного статичного сайта используется СУБД. Не важно, MySQL это будет или тот же PostgreSQL. При проектировании БД залогом избавления от 90% проблем в будущем — это грамотное использование типов данных, расстановка индексов, не говоря уже об осторожном обращении с тремя степенями нормализации. Если же «специалист» уже на подготовительном этапе не владеет инструментом с которым работает, то гнать таких надо в шею, пока не научатся.

                                                                                        И совершенно не обязательно читать всю документацию по СУБД. Я не считаю проблемой время от времени зарываться в маны и обсуждать с коллегами сложные моменты при работе с СУБД. Но, простите меня за категоричность, не знание основ ставит на человеке крест как на специалисте.

                                                                                        Если к вам пришел на работу математик, которые не знает таблицы умножения, но при этом оправдывает это тем, что всего знать нельзя — это шарлатан.
                                                                                        • +1
                                                                                          Вы пишете, что таких спецов надо гнать в шею, а я дал им материал, и теперь ещё 50-100 человек знают немного больше. Может это подтолкнёт их с систематизированному изучению СУБД. И как сказано выше, «это общий вопрос по информатике».

                                                                                          Вы правы, разработчики должны знать, как устроены индексы, что такое B-tree, понимать почему в некоторых запросах индекс не используется и т.д. Но они этого не знают в подавляющем большинстве, а проекты есть и их надо делать.

                                                                                          Компании же редко занимаются повышение квалификации своих сотрудников, на универ надежды нет. Поэтому как можем, так и просвещаем… :)
                                                                                    • 0
                                                                                      храню в int.
                                                                                      а чтобы работали функции работы с датами, использую FROM_UNIXTIME(`int_timestamp`)
                                                                                      • +2
                                                                                        «многие разработчики не знают...»
                                                                                        вы на самом деле считаете, что таких людей можно назвать разработчиками?

                                                                                        и вы как-то странно подменяете понятия:
                                                                                        TIMESTAMP [...] Зависит от установленного часового пояса

                                                                                        это как же?? транспортировка сервера из Магадана в Москву запускает апдейт базы??

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

                                                                                        и вообще. для web приложений не вижу смысла импользовать тип данных, отличный от timestamp. даже если вам нужно на экране вывести просто дату, без времени, вы никогда не узнаете, какое именно число месяца писать, не зная точного времени.
                                                                                        • 0
                                                                                          Часовой пояс на сервере устанавливается не транспортированием сервера из Магадана в Москву :)
                                                                                          • 0
                                                                                            это была ирония.
                                                                                            если вы поменяете часовой пояс на сервере без транспортировки, то значение полей timestamp не поменяется.
                                                                                            • –1
                                                                                              Значение, которое хранится в базе не поменяется, измениться его отображение при SELECT.
                                                                                              • +1
                                                                                                так потому и нужно писать, что зависит ОТОБРАЖЕНИЕ а не значение
                                                                                                • 0
                                                                                                  Так и написано:
                                                                                                  >> Зависит от установленного часового пояса.… Эта зависимость проявляется при отображении значения поля.

                                                                                                  • +1
                                                                                                    вот что написано:

                                                                                                    TIMESTAMP
                                                                                                    Хранит 4-байтное целое число, равное количеству секунд, прошедших с полуночи 1 января 1970 года по усреднённому времени Гринвича (т.е. нулевой часовой пояс, точка отсчёта часовых поясов). Зависит от установленного часового пояса.
                                                                                                    • –1
                                                                                                      >> Зависит от установленного часового пояса.
                                                                                                      Тип данных TIMESTAMP зависит от часового пояса. Дальше разъяснение, что эта зависимость проявляется в отображении данных в SELECT. Всё верно!

                                                                                                      Спор бесполезный. И так все уже поняли что к чему.
                                                                                                      • +1
                                                                                                        надеюсь, что вы никогда не будете писат манов.
                                                                                                        • 0
                                                                                                          не надейтесь :)
                                                                                                          • 0
                                                                                                            Не сбивайте с толку народ, поправьте пожалуйста что TIMESTAMP от часового пояса не зависит.
                                                                                                            Не важно какие часовые пояса настроены на серверах, в один момент времени значение TIMESTAMP для них будет одно и то же.

                                                                                                            А то вы путаете значение TIMESTAMP с его «отображением с использованием преобразования с поправкой на timezone». Не айс…
                                                                                      • +2
                                                                                        Прочитав комменты к топику понял, откуда у меня на работе гениальные скрипты.
                                                                                        • 0
                                                                                          Спасибо за обзор.
                                                                                          • 0
                                                                                            В поле какого типа лучше реализовать хранение времени в милисекундах?
                                                                                            datetime и timestamp тут вообще никак не подходят.
                                                                                            • 0
                                                                                              разделить время на секундную и миллисекундную части, первая часть — таймстемп или dt, вторая — инт
                                                                                            • 0
                                                                                              Всегда использую DATETIME при селектах юзаю DATE_FORMAT(`somefield`, '%d.%m.%Y в %H:%i') as `when`
                                                                                              и никаких проблем
                                                                                              • +1
                                                                                                Вопрос на котором валится 90% собеседуемых программистов :)
                                                                                                • 0
                                                                                                  Я в смятении, парни. Ну мало того, что некоторые в этой теме даже не знают чем временные типы данных отличаются друг от друга. Так еще и находятся те, кто минусуют комментарии и даже (о боже) срут в карму за попытки объяснить и разжевать им информацию. При этом ни на один мой коммент никто не удосужился ответить хоть что-нибудь внятное и объяснить мне в чем я не прав, видимо кроме как на «кнопоньку давить», более эти люди ничего не могут. Мне обычно глубоко насрать на это, но не в данном случае. Свинство какое-то.
                                                                                                  • 0
                                                                                                    Не отчаивайтесь, истина размножается спорами
                                                                                                    • +2
                                                                                                      Да я и не отчаиваюсь, просто неприятно такое поведение.
                                                                                                      Кстати не знаю как истина, но знания распространяются скорее как вирусы, через носителей. Заткни всех что-то знающих — и знаний не станет вместе с ними.
                                                                                                  • 0
                                                                                                    а зачем вы пишите о NOW() в TIMESTAMP??
                                                                                                    значение TIMESTAMP обновляется само при создании строки или при апдейте какого-то из полей.

                                                                                                    то есть в поле TIMESTAMP у нас всегда будет время создания этой строки в базе или время её последнего редактирования.

                                                                                                    ИМХО
                                                                                                    а вот применение TIMESTAMP в иных вариантах — лично для меня не совсем удобно.
                                                                                                    но это всего лишь дело вкуса.
                                                                                                    • 0
                                                                                                      В закладки
                                                                                                      • 0
                                                                                                        Для тех, кто не особо понял, советую прочитать вот это: habrahabr.ru/blogs/mysql/69983/
                                                                                                        • 0
                                                                                                          Кто-нибудь скажите, а почему если TIMESTAMP это по сути юниксовое время (с 1970 года), то откуда MySQL берет значения '0000-00-00 00:00:00'.
                                                                                                          Например вот выдержка из одной из моих таблиц:

                                                                                                          first_seen timestamp DEFAULT '0000-00-00 00:00:00',
                                                                                                          last_seen timestamp DEFAULT '0000-00-00 00:00:00',

                                                                                                          И реально, SELECT дает значения '0000-00-00 00:00:00'.

                                                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.