Come posso ottenere il fuso orario del server locale senza fare affidamento su php.ini o altri file di configurazione?Come posso ottenere il fuso orario del server locale?
Sto cercando un'uscita simile all'uscita di date('e'). per esempio. "UTC", "GMT" o "Atlantico/Azzorre".
Ho bisogno di sapere questo in modo che possa conoscere il fuso orario MySQL.
Se siete su * nix, chiamate del sistema date utilizzando popen:
popen("date +%Z");
Per Windows: WMi http://pastebin.com/qhmvEvP0 – user956584
Se stai usando una piattaforma di hosting basato su Linux/Unix, è possibile utilizzare l'output del comando date con la formattatore "fuso orario alfabetico abbreviazione" in quanto tale:
$systemTimeZone = system('date +%Z');
Tuttavia, va notato che non si deve necessariamente fare affidamento sulla fuso orario del sistema e che si dovrebbe invece usare date_default_timezone_set (o la date.timezone php.in impostazione) per impostare il fuso orario richiesto.
modifica la mia domanda in modo da poter capire cosa voglio fare – dvdx
@dvdx Per quale motivo ti serve una stringa come "America/New York"? –
perché America/New York genererà uno dei MOLTI nell'elenco dei formati di fuso orario supportati trovato qui: http://www.php.net/manual/en/timezones.php – SoLoGHoST
su Linux/Unix i usano
shell_exec("date +%Z");
in realtà non hanno bisogno di sapere che cosa "fuso orario" MySQL è in esecuzione - si deve semplicemente bisogno di sapere la differenza per UTC.
per ottenere che si può semplicemente chiedere di MySQL:
SELECT TIMESTAMPDIFF(HOUR, UTC_TIMESTAMP, NOW())
Poiché il valore di NOW() è basato sul fuso orario MySQL è in esecuzione, che leggerà la differenza tra NOW() e il tempo UTC, in ore. È quindi possibile utilizzare tale valore per creare un timestamp completo come 2016-04-15T15:52:01+01:00 che può essere utilizzato in DateTime::__construct().
È quindi possibile lasciare che PHP preoccuparsi per la differenza dei fusi orari tra i server applicazioni e database confrontando DateTime oggetti ... e che dovrebbe lavoro su tutti i sistemi.
Questo non fornisce il fuso orario effettivo, solo l'effetto del fuso orario. Alcuni fusi orari si sovrappongono in particolare con l'ora legale o quando vengono modificati. – jgmjgm
@jgmjgm - equo punto, non ero convinto che l'OP * davvero * necessitasse di qualcosa come la stringa 'GMT' se vedi cosa intendo ... non ne hai bisogno per nessun tipo di calcolo ti dà solo una stringa più leggibile. Penso che stavo cercando di fornire una soluzione alternativa a ciò che sospettavo fosse il problema di fondo piuttosto che rispondere effettivamente alla domanda "come-era" ... era un po 'di tempo fa;) – CD001
è possibile ottenere il fuso orario del server da questo. echo date_default_timezone_get();
Queste risposte non sono buone. Non conosco un modo portatile per farlo.
Per Linux qui è un'opzione: https://bojanz.wordpress.com/2014/03/11/detecting-the-system-timezone-php/
La data soluzione gli altri stanno elencando potrebbe non essere accurato come il problema è in Linux e l'utilità data (gnuutils, gnulib) erediterà lo stesso problema.
Se si imposta il fuso orario in Europa/Berlino e quindi chiedere la data per il fuso orario che mi darà CET.
Il modo per ottenere il fuso orario in Linux è come questo:
#include <time.h>
#include <stdio.h>
extern char *tzname[2];
extern long timezone;
extern int daylight;
void main() {
tzset();
printf(tzname[0]);
}
Il problema è che i file di zona non includono il loro nome, solo l'elenco dei fusi orari genitore o qualcosa del genere.
CET non è la stessa della zona Europa/Berlino. Se metto CET in date, le date possono essere calcolate in modo errato. A volte questo non importa come alcuni paesi hanno utilizzato un fuso orario per decenni, ma a volte può essere importante.
Utilizzando Zdump ecco un diff tra CET e Europe/Berlin:
> Fri Mar 31 23:06:31 1893 UTC = Fri Mar 31 23:59:59 1893 LMT isdst=0 gmtoff=3208
> Fri Mar 31 23:06:32 1893 UTC = Sat Apr 1 00:06:32 1893 CET isdst=0 gmtoff=3600
< Sun Sep 16 00:59:59 1945 UTC = Sun Sep 16 02:59:59 1945 CEST isdst=1 gmtoff=7200
< Sun Sep 16 01:00:00 1945 UTC = Sun Sep 16 02:00:00 1945 CET isdst=0 gmtoff=3600
< Sun Apr 3 00:59:59 1977 UTC = Sun Apr 3 01:59:59 1977 CET isdst=0 gmtoff=3600
... SNIP about a dozen ...
< Sun Sep 30 01:00:00 1979 UTC = Sun Sep 30 02:00:00 1979 CET isdst=0 gmtoff=3600
> Wed May 23 23:59:59 1945 UTC = Thu May 24 01:59:59 1945 CEST isdst=1 gmtoff=7200
... SNIP couple dozen...
> Sun Oct 2 01:00:00 1949 UTC = Sun Oct 2 02:00:00 1949 CET isdst=0 gmtoff=3600
Alcuni di questi potrebbe anche non importa se si sta utilizzando un unixtime ma si può chiaramente vedere qui che negli anni '70 qualcuno vorrebbe . Ci sono probabilmente alcuni altri fusi orari con modifiche molto più recenti che si interromperanno utilizzando il risultato di tzset. Per molti questo sarebbe un problema marginale, ma se ti influenza il risultato probabilmente non sarà piacevole.
Non so cosa sia la convenzione per Windows o se c'è lo stesso problema. C'è un'eccezione a questo problema. Se il fuso orario del sistema è uno dei principali (come GMT, UTC, CET, ecc.), Allora non penso che questo problema dovrebbe verificarsi.
Tuttavia la tua domanda è in ultima analisi, su MySQL:
SELECT IF(@@global.time_zone = 'SYSTEM', @@global.system_time_zone, @@global.time_zone) AS time_zone;
Se è impostato su SYSTEM sarà anche subire la stessa sorte di PHP e tzset. Ho controllato il server di un amico e c'è spesso differenza di un'ora perché MySQL converte Europa/Londra in GMT. GMT non include BST che è causa di molti problemi. Internamente MySQL potrebbe andare bene perché usa ancora/etc/localtime che punta al file giusto anche se MySQL riporta il nome sbagliato ma se prendi quel nome sbagliato e lo usi per caricare il fuso orario con qualcos'altro allora i due potrebbero non avere lo stesso fuso orario.
Anche se si è tentato di includere DST, non sarebbe una soluzione perfetta. Se l'istanza MySQL utilizza SYSTEM, potresti voler vedere se è possibile convertire le date da quella in UTC (o la data/ora del PHP) che potrebbero essere dolorose per le prestazioni. In teoria potresti provare a rilevare la forza bruta, ma non lo consiglierei. Puoi anche provare a impostare il fuso orario nella variabile di sessione e MySQL potrebbe convertirsi automaticamente, ma stai attento a essere sempre sicuro e sempre RTM (se non funziona usa la fonte).
Quale sistema operativo si desidera eseguire? – alexn