Forum Moderators: open
I use ADDDATE in and strtotime() out. Straightforward except for daylight savings time. Test code like this:
$setSQL = "
UPDATE Test_Table SET FutureTime = ADDDATE(now(), INTERVAL 1334 HOUR)
WHERE UserID = 0";
$Result1 = mysql_query($setSQL) or die(mysql_error());$query_Check = "
SELECT FutureTime,
now() as Current
FROM Test_Table
WHERE UserID = 0";
$check = mysql_query($query_Check) or die(mysql_error());
$row_check = mysql_fetch_assoc($check);$then = strtotime($row_check['FutureTime']);
$now = strtotime($row_check['Current']);echo "difference is " . ($then - $now) / 60 / 60;
Now broadly speaking I suspect there are a few ways to solve this. But I'm not knowledgeable enough to weigh them. So I would appreciate some advice on how you would fix this contradiction.
As I say there are a number of variations on this. Occasionally I want to compare to a manually-set system event and so I use mktime() without a db call, and it would be nice if the method here and the method there were compatible. But perhaps not essential?
Anyway, whatever you think would be the simplest / most flexible solution I'd appreciate hearing. If it matters, the server in question is a VPS so I believe I can control system time but not hardware time.
That's sort of how I was leaning, but help my reasoning on this please:
If I do all the calculations in MySQL, it will be consistent. But what happens when we get up to that DST hour? It seems to me that the clock would jump ahead and we'll lose an hour anyway, since MySQL never adjusted for it.
And then in the fall, it would back the clock up and re-count that hour. On both occasions it will ultimately mark the wrong time, because MySQL's ADDDATE() doesn't adjust for DST, but it is ultimately affected by it when the server clock changes.
Which leads me to conclude that only PHP is correct and I should do all the calculations there instead. But to my knowledge none of the PHP functions are as simple as ADDDATE, and then I have to give special concern to formatting.
