Primero, he escrito sobre esto con mucho detalle antes, así que lea mis respuestas aquí y aquí , así como esta publicación de blog de Lau Taarnskov .
Con respecto específico a MySQL, generalmente no desea utilizar un TIMESTAMP campo para la hora local de un evento futuro, ya que se convertirá de la zona horaria de la sesión a UTC en el momento de la escritura y volverá a convertir de UTC a la zona horaria de la sesión en el momento de la lectura. Incluso si estos son los mismos identificadores de zona horaria (que no tienen que serlo), no hay garantía de que los datos de la zona horaria no cambien para una o ambas zonas horarias entre el momento en que escribe los datos y el evento. tiene lugar.
En su lugar, utilice un DATETIME campo, que no realiza conversiones de zona horaria implícitas. Obtienes el valor exacto que escribiste. Almacene la hora local del evento y almacene un VARCHAR campo que contiene el identificador de zona horaria para el evento. Esta es la única forma de conservar la intención original del usuario.
La justificación y los casos límite se describen en las respuestas que di anteriormente.
