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

Hvordan får jeg den aktuelle tidszone i MySQL?

Fra manualen (afsnit 9.6 ):

De aktuelle værdier for de globale og klientspecifikke tidszoner kan hentes på denne måde:
mysql> SELECT @@global.time_zone, @@session.time_zone;

Rediger Ovenstående returnerer SYSTEM hvis MySQL er indstillet til at bruge systemets tidszone, hvilket er mindre end nyttigt. Da du bruger PHP, hvis svaret fra MySQL er SYSTEM , kan du så spørge systemet, hvilken tidszone det er bruger via date_default_timezone_get . (Selvfølgelig, som VolkerK påpegede, kan PHP køre på en anden server, men som antagelser går, forudsat at webserveren og DB-serveren, den taler med, er indstillet til [hvis ikke faktisk i ] den samme tidszone er ikke en stor spring.) Men pas på, at du (som med MySQL) kan indstille den tidszone, som PHP bruger (date_default_timezone_set ), hvilket betyder, at den muligvis rapporterer en anden værdi, end den OS bruger. Hvis du har kontrol over PHP-koden, bør du vide, om du gør det, og være okay.

Men hele spørgsmålet om, hvilken tidszone MySQL-serveren bruger, kan være en tangent, for at spørge serveren, hvilken tidszone den er i, fortæller dig absolut ingenting om data i databasen. Læs videre for detaljer:

Yderligere diskussion :

Hvis du har kontrol over serveren, kan du selvfølgelig sikre dig, at tidszonen er en kendt mængde. Hvis du ikke har kontrol over serveren, kan du indstille den tidszone, der bruges af din forbindelse sådan her:

set time_zone = '+00:00';

Det indstiller tidszonen til GMT, så eventuelle yderligere operationer (såsom now() ) vil bruge GMT.

Bemærk dog, at tids- og datoværdier ikke er gemt med tidszoneoplysninger i MySQL:

mysql> create table foo (tstamp datetime) Engine=MyISAM;
Query OK, 0 rows affected (0.06 sec)

mysql> insert into foo (tstamp) values (now());
Query OK, 1 row affected (0.00 sec)

mysql> set time_zone = '+01:00';
Query OK, 0 rows affected (0.00 sec)

mysql> select tstamp from foo;
+---------------------+
| tstamp              |
+---------------------+
| 2010-05-29 08:31:59 |
+---------------------+
1 row in set (0.00 sec)

mysql> set time_zone = '+02:00';
Query OK, 0 rows affected (0.00 sec)

mysql> select tstamp from foo;
+---------------------+
| tstamp              |
+---------------------+
| 2010-05-29 08:31:59 |      <== Note, no change!
+---------------------+
1 row in set (0.00 sec)

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2010-05-29 10:32:32 |
+---------------------+
1 row in set (0.00 sec)

mysql> set time_zone = '+00:00';
Query OK, 0 rows affected (0.00 sec)

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2010-05-29 08:32:38 |      <== Note, it changed!
+---------------------+
1 row in set (0.00 sec)

Så at kende serverens tidszone er kun vigtigt i forhold til funktioner, der får tiden lige nu, såsom now() , unix_timestamp() , etc.; det fortæller dig ikke noget om, hvilken tidszone datoerne i databasedataene bruger. Du kan vælge at antage de blev skrevet ved hjælp af serverens tidszone, men den antagelse kan meget vel være mangelfuld. For at kende tidszonen for eventuelle datoer eller tidspunkter, der er gemt i dataene, skal du sikre, at de er gemt med tidszoneoplysninger eller (som jeg gør) sikre, at de altid er i GMT.

Hvorfor er det forkert at antage, at dataene er skrevet ved hjælp af serverens tidszone? Nå, for det første kan dataene være skrevet ved hjælp af en forbindelse, der indstillede en anden tidszone. Databasen kan være blevet flyttet fra en server til en anden, hvor serverne var i forskellige tidszoner (det stødte jeg på, da jeg arvede en database, der var flyttet fra Texas til Californien). Men selvom dataene er skrevet på serveren, med dens aktuelle tidszone, er det stadig tvetydigt. Sidste år, i USA, blev sommertid slået fra kl. 02.00 den 1. november. Antag, at min server er i Californien og bruger Pacific-tidszonen, og at jeg har værdien 2009-11-01 01:30:00 i databasen. Hvornår var det? Var det kl. 01.30 den 1. november PDT eller kl. 01.30 den 1. november PST (en time senere)? Du har absolut ingen mulighed for at vide det. Moral:Gem altid datoer/klokkeslæt i GMT (som ikke gør sommertid) og konverter til den ønskede tidszone efter behov.



  1. Hvordan ved man, hvilken partition der vil blive brugt i Postgres hash partitionering?

  2. SQL opdatering top1 række forespørgsel

  3. Hvorfor rapporterer MySQL en syntaksfejl på FULL OUTER JOIN?

  4. Postgresql-adapter (pg):kunne ikke oprette forbindelse til serveren