Поэтому в стандарте sql есть datetime/timestamp with time zone. Но у mysql как всегда свой путь)А потом оказывается что появляется TZ
Или интересные моменты связанные с невалидной датой. Сначала база была на сервере с одной TZ а потом после переезда стала на другой.
Т.е. когда девопсы и разработчики понимают что они делают, то вообще пофигу в чем хранить, но обычно как раз наоборот
А часовой пояс здесь не причем полагаю.
это да
Особенно учитывая легаси старых версий - это вообще интересный набор багов при обновлении/импорте/экспорте
Это кто так решил?
class CustomEloquentBuilder extends Builder
{
public function whereDay($column, $operator, $value = null)
{
print 123; // -> Эта функция переопределяется и результат есть, когда я ее запрашиваю в SELECT-запросах
exit();
}
/**
* Add a date based (year, month, day, time) statement to the query.
*
* @param string $type
* @param string $column
* @param string $operator
* @param mixed $value
* @param string $boolean
* @return $this
*/
protected function addDateBasedWhere($type, $column, $operator, $value, $boolean = 'and')
{
print 12321; // -> сюда не попадаю...
exit(); // -> Но вот эта функцию "addDateBasedWhere" почему-то все равно использует родительский "addDateBasedWhere"
}Полагаю когда нужно учитывать временную зону для выборки SELECT-запросов это уже какая-то другая логика. Почему я показывая сайт в другом регионе россии должен корректировать часовой пояс?
классика!
нет слов....
Юникс-таймстемп не всегда поможет. Допустим, надо запланировать событие, которое произойдёт в будущем в определенную дату и время по конкретному часовому поясу. С Новым годом поздравить, например. Если в промежутке между записью в базу и временем самого события tzdata для часового пояса изменится, все сломается.
Всегда при подключении к БД ставлю пояс, в PHP bootstrap тоже, если подразумевается чехарда с поясами, тогда в 0.
Да когда с НГ поздравить часовой пояс надо учитывать...
Сочувствую.
Дата пишется БЕЗ TZ.
Не пойму - я для whereDay планирую сделать FROM_UNIXTIME - чем мне это грозит?
Тебе? Геморроем. Ибо часы, проведённые за отладкой этого говна, здоровье не улучшают.
Да оно все равно сломается если попадет на несуществующее время, например на пробел в переводе летнего/зимнего времени
datetime почти пофиг на TZ, timestamp - нет
Если такое изменение в TZ произойдёт после записи в базу, это проблема программы.
<?=DateTime::createFromFormat("Y-m-d", "2021-03-43")->format("Y-m-d");