Tout d'abord, j'ai déjà écrit à ce sujet en détail, alors veuillez lire mes réponses ici et ici , ainsi que cet article de blog de Lau Taarnskov .
En ce qui concerne spécifiquement MySQL, vous ne souhaitez généralement pas utiliser un TIMESTAMP champ pour l'heure locale d'un événement futur, car il sera converti du fuseau horaire de la session en UTC au moment de l'écriture, et reconverti de l'UTC au fuseau horaire de la session au moment de la lecture. Même s'il s'agit des mêmes identifiants de fuseau horaire (ce qui n'est pas obligatoire), il n'y a aucune garantie que les données de fuseau horaire ne changeront pas pour l'un ou les deux fuseaux horaires entre le moment où vous écrivez les données et le moment où l'événement a lieu.
Utilisez plutôt un DATETIME , qui n'effectue aucune conversion de fuseau horaire implicite. Vous obtenez la valeur exacte que vous avez écrite. Stockez l'heure locale de l'événement et stockez un VARCHAR champ contenant l'identifiant du fuseau horaire de l'événement. C'est le seul moyen de conserver l'intention d'origine de l'utilisateur.
La justification et les cas extrêmes sont tous décrits dans les réponses que j'ai données précédemment.
