Start / End of Summer Schedule: problem with date verification of type "greater than"

2

Every year I have two problems, one when summer time begins and the other when it's over.

Anyway, yesterday the clock was delayed in an hour that created a giant problem.

The page should allow the user to access it only with a time interval, in this case of 10 minutes.

To do this, do the following:

Imagine:

<?

// $data = date('Y-m-d H:i:s');
$data = '2016-02-20 23:50:00';

$mysqli->query("SELECT null FROM tabela WHERE Data >= '$data' AND User = '1")

if($mysqli->num_rows <= 0){

$dataProxima = date('Y-m-d H:i:s', strtotime("+10 minutes");

$mysqli->query("INSERT INTO tabela VALUES (0, '$dataProxima', '1')");
// Isso irá permitir que o usuário somente entre na página depois de 10 minutos.


echo 'ok';
// Pagina é carregada

}else{

// echo 'falhou';

header('location: meusite.com');
exit;   

}

?>

In the table there is:

id | Data                 | User
1  | 2016-02-20 23:39:00  | 1

This example will return:

ok

In theory if there is no date greater than the current date will continue, if it will not fail.

But ...

When the daylight saving time ends, it will automatically return to 2016-02-20 23:00:00 , which will fail, even if in theory it has already passed the date.

Now, after the release schedule, the information will be:

$data = '2016-02-20 23:00:00';
// Irá retornar: falhou

Is there any correction that can be done directly to correct these situations?

There's still a bigger problem!

If the database data is:

id | Data
1  | 2016-02-21 00:01:00

You will have to wait another hour to return "ok", instead of one minute.

Is there a MySQL function that will compensate for this daylight saving time difference using DATETIME ?

    
asked by anonymous 21.02.2016 / 13:15

1 answer

2

Just use GMT instead of local time:

$dataProxima = gmdate('Y-m-d H:i:s' ...

According to documentation :

  

gmdate - Format a date / time GMT / CUT
  Identical to the date () function except that the time is in Greenwich Mean Time (GMT).

If it was my code, I would not use either date, I'd use UNIX Timestamp , and would make the comparison in integers:

$tempoFuturo = time() + 600;

This solution is much simpler, and it avoids ambiguities. Since the result of time() is a value in seconds, we add 600 seconds to give a 10 minute interval. Of course, we avoid string × date operations in DB. Comparisons with integers are more efficient.

    
21.02.2016 / 13:49