Одно из устойчивых мнений — время в базе надо хранить в виде целого числа секунд, прошедших с 1-го января 1970 года (unix timestamp). Традиционные же временные функции пхп (php): time, date, mktime,— обязательно учтут локальное время сервера. Зададим два события в локальном времени: полночь 1 октября 2008 года:
< ?php echo date('U = r',mktime(0,0,0,10,1,2008))?>
//outputs: 1222804800 = Wed, 01 Oct 2008 00:00:00 +0400
< ?php echo gmdate('U = r',mktime(0,0,0,10,1,2008))?>
//outputs: 1222804800 = Tue, 30 Sep 2008 20:00:00 +0000
и 23:59:59 31 октября 2008 года:
< ?php echo date('U = r',mktime(0,0,0,10,31,2008))?>
//outputs: 1225486799 = Fri, 31 Oct 2008 23:59:59 +0300
< ?php echo gmdate('U = r',mktime(0,0,0,10,31,2008))?>
//outputs: 1225486799 = Fri, 31 Oct 2008 20:59:59 +0000
Казалось бы, разница таймштампов, деленная на количество секунд в сутках (86 400), даст 31 осенний день. На деле же выйдет 31 день и 1 час. Так, биллинг контейнерного терминала, взимающего плату за хранение оборудования включительно с днями прибытия и отправки, округлил полученный результат до 32 дней.
Скорректировать это недоразумение можно, учтя разницу в секундах с Гринвичем date(’Z',$timestamp).
$days=ceil(($out-$in+date(’Z',$out)-date(’Z',$in))/86400);