Lavorare con i fusi orari quando si memorizzano le date in mysql

Penso che devi scavare un po 'più a fondo rispetto all'impostazione di un UTC_DATE predefinito. Un valore predefinito di UTC_DATE potrebbe aiutare a risolvere il problema, ma non risolve il problema più ampio relativo al lavoro con i fusi orari nelle applicazioni.

Esistono tre modi in cui i fusi orari vengono generalmente gestiti:

1. Non lo sono. Supponiamo che tutti gli utenti si trovino sullo stesso fuso orario del server. Nella maggior parte dei casi, questo è un approccio terribile. Il problema con l'approccio al fuso orario che scegli è che è quasi impossibile cambiare dopo il fatto, e c'è una buona possibilità che qualcuno che inizi così abbia bisogno di cambiarlo dopo. Oltre a ciò, se il fuso orario del server cambia (inavvertitamente o in altro modo), questo potrebbe causare seri effetti collaterali, fino al punto in cui l'intero sistema potrebbe crollare.
2. L'utente specifica il fuso orario per il proprio account, Store UTC. In questo caso, l'utente, una volta creato un profilo, seleziona il fuso orario che desidera utilizzare per il proprio account. Questa impostazione è memorizzata nel database con quell'account utente. Nel frattempo, tutte le date memorizzate nel database vengono memorizzate utilizzando un fuso orario standard (naturalmente, questo è UTC). Ora, prima di memorizzare una data che proviene dall'utente, calcola il fuso orario dell'utente e compensalo di conseguenza (per assicurarti che la data sia memorizzata in UTC). Prima di visualizzare una data, usa l'offset del fuso orario per adattarlo al livello di presentazione. Questo approccio è significativamente migliore di # 1, ma presenta ancora alcuni inconvenienti. Vale la pena notare che gli svantaggi con questo non sono probabilmente del tipo che potrebbe rendere l'applicazione inutilizzabile, come nel caso del # 1.
3. Usa fusi orari client / agente, Store UTC qualsiasi client web moderno dovrebbe essere in grado di presentare il fuso orario corrente al server. Pianificare di archiviare tutte le date lato server in un fuso orario standard (UTC) e pianificare che tutte le date passate al server siano state compensate da UTC dal client. Questo rilascia completamente il server dal prendersi cura di eventuali fusi orari (davvero a portata di mano), ma pone un carico maggiore sul front end per garantire che converta tutto in UTC da Local (a volte un dolore, ma è comunque responsabilità del cliente in ogni caso .. .). Allo stesso modo, il server dovrebbe pubblicare solo date UTC e il client dovrebbe convertirle in ora locale per scopi di visualizzazione. Dal mio punto di vista, questo è l'unico modo corretto per gestire i fusi orari.

La cosa importante da ricordare è che una volta scelto un approccio, cambiarlo in seguito è estremamente difficile! Scegli saggiamente:)

Crea semplicemente la tua tabella per archiviare UTC_DATE come valore DEFAULT .

CREATE MyTable
...
  MyColumn DATE DEFAULT UTC_DATE
...

Per chiunque abbia un problema simile in futuro, fai riferimento a questa discussione molto approfondita sul tempo nella programmazione . Mi ha aiutato molto.

Uno dei modi per gestire il tempo è

negozio:

1. Ottieni ora locale utilizzando una libreria JavaScript o qualsiasi altro front-end.

2. Converti in timestamp UTC Unix nel front-end JS.

3. Passa a back end come UTC e memorizza nel database come UTC.

e recupera:

1. Scaricalo dal database come UTC,

2. Passa attraverso il back-end a JavaScript come UTC,

3. Avere JS (front-end) convertirlo in ora locale.

In breve, gestisci sempre il tempo come UTC nel back-end e nel database. Avere il front end convertire il tempo in locale perché solo il front-end può indovinare quale fuso orario l'utente è, e indovina piuttosto bene la maggior parte del tempo. Sebbene a causa della complessità di fusi orari, DST, utenti in viaggio, VPN, ecc. Non sembra essere una soluzione a prova di errore al 100%.