Comment puis-je obtenir le fuseau horaire du serveur local sans utiliser php.ini ou d'autres fichiers de configuration? Je recherche une sortie similaire à la sortie date('e'). par exemple. "UTC", "GMT" ou "Atlantic/Açores".Comment puis-je obtenir le fuseau horaire du serveur local?
J'ai besoin de savoir ceci pour que je puisse connaître le fuseau horaire de MySQL.
Si vous êtes sur * nix, appelez date de système en utilisant popen:
popen("date +%Z");
Pour Windows: WMi http://pastebin.com/qhmvEvP0 – user956584
Si vous utilisez une plate-forme d'hébergement Linux/Unix, vous pouvez utiliser la sortie de la commande date avec le formatter « abréviation de fuseau horaire alphabétique » en tant que tel:
$systemTimeZone = system('date +%Z');
Cependant, il convient de noter que vous devez compter pas nécessairement sur le fuseau horaire du système et que vous devriez utiliser date_default_timezone_set (ou date.timezone php.in i réglage) pour régler le fuseau horaire requis.
Je modifie ma question pour que vous puissiez comprendre ce que je veux faire – dvdx
@dvdx Qu'est-ce que vous avez besoin d'une chaîne comme "Amérique/New York" pour si? –
parce qu'American/New York produira l'un des nombreux messages sur la liste des formats de fuseau horaire disponibles: http://www.php.net/manual/en/timezones.php – SoLoGHoST
Sur linux/unix-je utiliser
shell_exec("date +%Z");
Vous n'avez pas vraiment besoin de savoir ce que « fuseau horaire » MySQL fonctionne sur - vous devez simplement savoir la différence UTC.
Pour obtenir que vous pouvez simplement demander à MySQL:
SELECT TIMESTAMPDIFF(HOUR, UTC_TIMESTAMP, NOW())
Puisque la valeur de NOW() est basée sur le fuseau horaire MySQL est exécuté, qui va lire la différence entre NOW() et l'heure UTC, en heures. Vous pouvez ensuite utiliser cette valeur pour créer un horodatage complet tel que 2016-04-15T15:52:01+01:00 qui peut être utilisé dans DateTime::__construct().
Vous pouvez alors laisser PHP vous soucier de la différence entre les fuseaux horaires des serveurs d'applications et bases de données en comparant les objets DateTime ... et que devrait travailler sur tous les systèmes.
Ceci ne donne pas le fuseau horaire, seulement l'effet du fuseau horaire. Certains fuseaux horaires se chevauchent en particulier avec DST ou quand ils sont modifiés. – jgmjgm
@jgmjgm - juste point, je n'étais pas convaincu que l'OP * vraiment * besoin de quelque chose comme la chaîne 'GMT' si vous voyez ce que je veux dire ... vous n'en avez pas besoin pour tout type de calculs qu'il vous donne une chaîne plus lisible. Je pense que j'essayais de fournir une solution alternative à ce que je soupçonnais le problème sous-jacent plutôt que de répondre réellement à la question «tel quel» ... c'était il y a un certain temps;) – CD001
vous pouvez obtenir le fuseau horaire de votre serveur par ceci. echo date_default_timezone_get();
Ces réponses ne sont pas bonnes. Je ne connais pas de façon portable de le faire.
Pour Linux est une option ici: https://bojanz.wordpress.com/2014/03/11/detecting-the-system-timezone-php/
Les autres solution date énumèrent pourrait ne pas être précis que le problème est sous Linux et l'utilitaire de date (gnuutils, gnulib) héritera le même problème.
Si je règle le fuseau horaire Europe/Berlin et que je demande la date du fuseau horaire, il me donnera CET.
La manière d'obtenir le fuseau horaire dans Linux est comme ceci:
#include <time.h>
#include <stdio.h>
extern char *tzname[2];
extern long timezone;
extern int daylight;
void main() {
tzset();
printf(tzname[0]);
}
Le problème est que les fichiers de zone ne comprennent pas leur nom, seule la liste des fuseaux horaires des parents ou quelque chose comme ça.
CET n'est pas la même que la zone Europe/Berlin. Si je mets CET dans les dates peuvent être calculés incorrectement. Parfois, cela n'a pas d'importance car certains pays utilisent un fuseau horaire depuis des décennies, mais parfois cela peut avoir de l'importance.
L'utilisation zdump ici est un diff entre CET et 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
Certains d'entre eux pourraient ne pas d'importance, même si vous utilisez un unixtime mais vous pouvez voir clairement ici que dans les années 70 Certains . Il y a probablement quelques autres fuseaux horaires avec des changements beaucoup plus récents qui casseraient en utilisant le résultat de tzset. Pour beaucoup, ce serait une question marginale mais si cela vous affecte, le résultat ne sera probablement pas agréable.
Je ne sais pas ce que la convention est pour windows ou s'il y a le même problème. Il existe une exception à ce problème. Si votre fuseau horaire est un root (comme GMT, UTC, CET, etc) alors je ne pense pas que ce problème devrait se produire.
Toutefois, votre question est en fin de compte sur MySQL:
SELECT IF(@@global.time_zone = 'SYSTEM', @@global.system_time_zone, @@global.time_zone) AS time_zone;
Si elle est réglée sur le système, il souffrira le même sort que PHP et tzset. J'ai vérifié le serveur d'un ami et il y a souvent une heure de différence parce que MySQL convertit l'Europe/Londres en GMT. GMT n'inclut pas BST qui est une cause de nombreux problèmes. En interne, MySQL pourrait bien fonctionner car il utilise toujours/etc/localtime pour pointer sur le bon fichier même si MySQL rapporte le mauvais nom mais si vous prenez le mauvais nom et l'utilisez pour charger le fuseau horaire avec autre chose, les deux ne peuvent pas avoir le même fuseau horaire.
Même si vous avez essayé d'inclure DST, ce ne serait pas une solution parfaite. Si vous utilisez MySQL, vous voudrez peut-être voir si vous pouvez convertir les dates en UTC (ou la date et l'heure PHP) ce qui peut être pénible pour les performances. En théorie, vous pouvez essayer de détecter la force brute, mais je ne le conseillerais pas. Vous pouvez également essayer de définir le fuseau horaire dans la variable de session et MySQL peut convertir automatiquement mais assurez-vous d'être sûr et toujours RTM (si cela ne fonctionne pas, utilisez la source).
Sur quel système d'exploitation voulez-vous cela? – alexn