php - utilisées - Champs de date-heure MySQL et heure avancée-comment faire référence à l'heure "supplémentaire"?




toutes les balises php pdf (4)

Mais comment sauvegarder quoi que ce soit à 01:30:00 -04: 00?

Vous pouvez convertir en UTC comme:

SELECT CONVERT_TZ('2009-11-29 01:30:00','-04:00','+00:00');

Encore mieux, enregistrez les dates sous forme de champ documentation . Cela est toujours stocké dans l'UTC, et l'UTC ne connaît pas l'heure d'été / d'hiver.

Vous pouvez convertir d'UTC en heure locale en utilisant CONVERT_TZ :

SELECT CONVERT_TZ(UTC_TIMESTAMP(),'+00:00','SYSTEM');

Où '+00: 00' est UTC, le fuseau horaire from, et 'SYSTEM' est le fuseau horaire local du système d'exploitation sur lequel MySQL s'exécute.

https://code.i-harness.com

J'utilise le fuseau horaire America / New York. À l'automne, nous "retombons" une heure - "gagner" une heure à 2h du matin. Au point de transition, les événements suivants se produisent:

il est 01:59:00 -04: 00
puis 1 minute plus tard, il devient:
01:00:00 -05: 00

Donc, si vous dites simplement «1 h 30», il est ambigu de savoir si vous faites allusion à la première fois que 1 h 30 survient ou que la première fois. J'essaie d'enregistrer des données de planification dans une base de données MySQL et je ne peux pas déterminer comment enregistrer correctement les heures.

Voici le problème:
"2009-11-01 00:30:00" est stocké en interne en tant que 2009-11-01 00:30:00 -04: 00
"2009-11-01 01:30:00" est stocké en interne en tant que 2009-11-01 01:30:00 -05: 00

C'est bien et assez attendu. Mais comment sauvegarder quoi que ce soit à 01:30:00 -04: 00 ? La documentation ne montre aucun support pour spécifier le décalage et, par conséquent, quand j'ai essayé de spécifier le décalage, il a été dûment ignoré.

Les seules solutions auxquelles j'ai pensé impliquent de configurer le serveur sur un fuseau horaire qui n'utilise pas l'heure avancée et qui effectue les transformations nécessaires dans mes scripts (j'utilise PHP pour cela). Mais cela ne semble pas devoir être nécessaire.

Merci beaucoup pour vos suggestions.


Ce thread m'a fait flipper puisque nous utilisons des colonnes TIMESTAMP avec On UPDATE CURRENT_TIMESTAMP (c'est-à-dire: recordTimestamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) pour suivre les enregistrements modifiés et ETL vers un datawarehouse.

Dans le cas où quelqu'un se demanderait, dans ce cas, TIMESTAMP se comporte correctement et vous pouvez différencier les deux dates similaires en convertissant TIMESTAMP en timestamp unix:

select TestFact.*, UNIX_TIMESTAMP(recordTimestamp) from TestFact;

id  recordTimestamp         UNIX_TIMESTAMP(recordTimestamp)
1   2012-11-04 01:00:10.0   1352005210
2   2012-11-04 01:00:10.0   1352008810

Je pense que le web.ivy.net/~carton/rant/MySQL-timezones.txt de micahwittman a la meilleure solution pratique à ces limitations de MySQL: Réglez le fuseau horaire de session à UTC quand vous vous connectez:

SET SESSION time_zone = '+0:00'

Ensuite, vous envoyez juste un timestamp Unix et tout devrait bien se passer.


Je travaillais sur le décompte des visites des pages et l'affichage des chiffres dans le graphique (en utilisant le plugin Flot jQuery). J'ai rempli la table avec des données de test et tout s'est bien passé, mais j'ai remarqué qu'à la fin du graphique, les points étaient un jour de congé selon les étiquettes sur l'axe des x. Après examen, j'ai remarqué que le compte de vues pour la journée 2015-10-25 a été extrait deux fois de la base de données et transmis à Flot, donc chaque jour après cette date a été déplacé d'un jour vers la droite.
Après avoir cherché un bug dans mon code pendant un moment, j'ai réalisé que cette date est celle où l'heure d'été a lieu. Puis je suis venu à cette page SO ...
... mais les solutions proposées étaient excessives pour ce dont j'avais besoin ou elles présentaient d'autres inconvénients. Je ne suis pas très inquiet de ne pas pouvoir distinguer entre les timestamps ambigus. J'ai juste besoin de compter et d'afficher les enregistrements par jour.

D'abord, je récupère la plage de dates:

SELECT 
    DATE(MIN(created_timestamp)) AS min_date, 
    DATE(MAX(created_timestamp)) AS max_date 
FROM page_display_log
WHERE item_id = :item_id

Puis, dans une boucle for, commençant par min_date , se terminant par max_date , par pas d'un jour ( 60*60*24 ), je récupère les comptes:

for( $day = $min_date_timestamp; $day <= $max_date_timestamp; $day += 60 * 60 * 24 ) {
    $query = "
        SELECT COUNT(*) AS count_per_day
        FROM page_display_log
        WHERE 
            item_id = :item_id AND
            ( 
                created_timestamp BETWEEN 
                '" . date( "Y-m-d 00:00:00", $day ) . "' AND
                '" . date( "Y-m-d 23:59:59", $day ) . "'
            )
    ";
    //execute query and do stuff with the result
}

Ma solution finale et rapide à mon problème était la suivante:

$min_date_timestamp += 60 * 60 * 2; // To avoid DST problems
for( $day = $min_date_timestamp; $day <= $max_da.....

Donc, je ne regarde pas la boucle au début de la journée, mais deux heures plus tard . Le jour est toujours le même, et je récupère toujours les comptes corrects, puisque je demande explicitement à la base de données pour les enregistrements entre 00:00:00 et 23:59:59 du jour, indépendamment de l'heure réelle de l'horodatage. Et quand le temps saute d'une heure, je suis toujours dans le bon jour.

Note: Je sais que c'est un sujet vieux de 5 ans, et je sais que ce n'est pas une réponse à la question OP, mais cela pourrait aider les gens comme moi qui ont rencontré cette page à chercher une solution au problème que j'ai décrit.







dst