Я пытаюсь преобразовать дату рождения из своей БД в DATE FORMat, но я столкнулся с проблемой наличия некоторых отрицательных значений в полях DOB, которые, когда я проверяю из онлайн-калькулятора FROM_UNIXTIME, тогда он дает другой результат, и если я проверю он с FROM_UNIXTIME(-957632400), тогда он всегда возвращает NULL для отрицательных значений. KIndly дайте мне знать, как я могу получить формат даты из такого формата UNIX, как из -957632400
Преобразование отрицательных значений из FROM_UNIXTIME
Ответ 1
Мы можем сделать это вместо этого:
FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND
Функция FROM_UNIXTIME ограничена допустимым диапазоном для TIMESTAMP данных TIMESTAMP, который является стандартным 32-битным диапазоном без знака int с 1970-01-01 по 2038-01 что-то. Другое программное обеспечение было обновлено для поддержки 64-битных целых чисел со знаком, но MySQL еще не обеспечивает эту функциональность (по крайней мере, в 5.1.x).
Обходной путь в MySQL - избегать использования TIMESTAMP данных TIMESTAMP и вместо этого использовать тип данных DATETIME, когда нам нужен больший диапазон (например, даты до 1 января 1970 г.).
Мы можем использовать функцию DATE_ADD для вычитания секунд с 1 января 1970 года, например:
SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)
NB Вам, вероятно, придется учитывать "смещения" часового пояса от UTC при выполнении этих типов вычислений. MySQL будет интерпретировать значения DATETIME, как указано в настройке time_zone текущего сеанса MySQL, а не в формате UTC (time_zone = '+00:00')
СЛЕДОВАТЬ ЗА:
Q: Хорошо, значит, если мы выберем даты ниже '1970-01-01 00:00:00', то отрицательное значение сохранится в БД, иначе оно будет положительным. Правильно? - мягкий гений
A: Эээ, нет. Если вы выберете значения даты/даты и времени до 1 января 1970 года, MySQL вернет значения DATE или DATETIME до 1 января 1970 года. Если вы сохраните значения DATE или DATETIME до 1 января 1970 года, MySQL сохранит значение DATE или DATETIME до 1 января 1970 года. 1970, в пределах допустимого диапазона, поддерживаемого этими типами данных. (что-то вроде 0001-01-01 до 9999?)
Если вам нужно хранить действительно большие положительные и отрицательные целые числа в базе данных, вы, скорее всего, сохраните их в столбце, определенном как BIGINT.
Внутреннее представление столбца DATE требует 3 байта памяти, а DATETIME требует 8 байтов памяти (до версии MySQL 5.6.4. Внутреннее представление и хранение значений DATE и DATETIME изменено в 5.6.4)
Так что нет, MySQL не хранит значения даты до 1970 года как "отрицательные целые числа".
Если немного подумать, MySQL может реализовать любой механизм хранения, какой захочет. (И каждый механизм хранения может сериализовать это представление на диск так, как ему хочется.)
Почему 3 байта на дату?
Один из вариантов, который есть в MySQL (и я не представляю, что это так), может состоять в том, чтобы разбить дату на составляющие года, месяца и дня.
Представление целочисленных значений в диапазоне - требует -
-
0 - 9999 -14 бит -
0 - 12 -4 бита -
0 - 31 -5 бит
Это в общей сложности 23 бита, что бывает удобно вписывается в 3 байта. Это просто демонстрирует, что MySQL не нужно представлять значения даты до 1 января 1970 года как отрицательные целые числа, поэтому мы не должны делать предположение, что это так. (Но мы действительно были бы обеспокоены таким уровнем детализации, если бы работали над механизмом хранения для MySQL.)
Ответ 2
От DATETIME к временной отметке unix:
SELECT TIMESTAMPDIFF(SECOND, FROM_UNIXTIME(0), '1956-12-24 01:06:49');
От метки времени до DATETIME:
SELECT DATE_ADD(convert_tz(FROM_UNIXTIME(0), @@session.time_zone,'+00:00'), INTERVAL -410914391 SECOND);