Mysql
 sql >> Database >  >> RDS >> Mysql

Memorizzazione delle informazioni sull'ora:Fuso orario richiesto?

Qualunque sia il modo in cui lo fai, fallirà in modi diversi a seconda di ciò che sta cambiando.

  1. Se memorizzi timestamp nel fuso orario corrispondente come 2013-12-29 12:34:56 America/New_York , questo fallirà se, ad esempio, il Bronx avvia improvvisamente il proprio fuso orario America/New_York_Bronx con un offset diverso e il tuo evento si trovava nel Bronx.

    Decidi quanto è probabile e quanto grave sarebbe un fallimento.

  2. Se memorizzi i timestamp in UTC e il fuso orario in cui si verifica l'evento ridefinisce il loro offset (ad es. spostando le date dell'ora legale o spostandosi completamente a un offset diverso), l'ora dell'evento potrebbe differire dall'ora effettiva dell'orologio a muro in quella posizione. Se memorizzi 2013-12-29 12:34:56 UTC per un evento alle 13:34:56 a Berlino, in Germania, e Berlino sposta l'ora legale, 2013-12-29 12:34:56 UTC ora potrebbe corrispondere alle 14:34:56 ora locale di Berlino, mentre l'evento si svolgerà ancora alle 13:34 ora locale.

    Decidi quanto è probabile e quanto grave sarebbe un fallimento.

  3. Se memorizzi il timestamp UTC e lo colleghi a una posizione fisica che poi colleghi a un fuso orario, puoi contrastare entrambi i problemi. Ma per questo dovrai memorizzare la posizione fisica precisa, non solo "New York", altrimenti hai solo il caso 1. con un ulteriore passaggio intermedio. Se memorizzi la posizione fisica precisa e disponi di un modo preciso per risolvere questa posizione in un fuso orario e mantieni aggiornato il database del fuso orario, puoi gestire praticamente tutti gli scenari di cambiamento.

    Decidi quanto è pratico e quanto vale per te questa precisione extra.