Web

Как я могу узнать часовой пояс локального сервера?

Как я могу получить часовой пояс локального сервера, не полагаясь на php.ini и другие файлы конфигурации?

Я ищу вывод, похожий на вывод date('e'). например. «UTC», «GMT» или «Атлантика/Азорские острова».

Мне нужно узнать, как определяется часовой пояс в  MySQL.

 

Ответ 1

Если вы используете хостинговую платформу на базе Linux/Unix, вы можете использовать вывод команды date с «буквенным сокращением часового пояса»:

$systemTimeZone = system('date +%Z');

 

Однако следует отметить, что вам не обязательно полагаться на часовой пояс системы и  вместо этого вы должны использовать date_default_timezone_set (или параметр date.timezone в php.ini) для установки необходимого часового пояса.

 

Ответ 2

Если вы используете * nix, вызовите системный  date, используя popen:

popen("date +%Z");

 

Ответ 3

В linux/unix я использую

shell_exec("date +%Z");

 

Ответ 4

Эти ответы неверные. Я не знаю переносимого способа сделать это.

Для Linux есть один вариант: https://bojanz.wordpress.com/2014/03/11/detecting-the-system-timezone-php/

Определение даты, перечисленное в других ответах, может быть неточным, поскольку проблема есть в Linux, и инструменты работы с  датой (gnuutils, gnulib) наследуют ту же проблему.

Если я установлю часовой пояс на Европу/Берлин, а затем запрошу дату для часового пояса, он даст мне CET.

Способ получения часового пояса в Linux выглядит следующим образом:

 #include <time.h>

 #include <stdio.h>

 

 extern char *tzname[2];

 extern long timezone;

 extern int daylight;

 

 void main() {

         tzset();

         printf(tzname[0]);

 }

 

Проблема в том, что файлы зон не содержат их имени, только список родительских часовых поясов или что-то в этом роде.

CET - это не то же самое, что зона Европа/Берлин. Если я введу среднеевропейское время, даты могут быть рассчитаны неправильно. Иногда это не имеет значения, поскольку некоторые страны используют один часовой пояс десятилетиями, но иногда это может иметь значение.

Используя zdump, можно увидеть разницу между CET и Европой/Берлином:

 >   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

 

Некоторые из этих результатов могут не иметь значения, если вы используете unixtime. Вероятно, есть несколько других часовых поясов с гораздо более поздними изменениями, которые могут сломаться, используя результат tzset. Для многих это будет второстепенной проблемой, но если это действительно важно вам, результат, скорее всего, не будет верным.

Я не знаю, есть ли какие-либо соглашения для Windows и есть ли в ней, такие же проблемы. Но есть исключение. Если часовой пояс вашей системы является корневым (например, GMT, UTC, CET и т. Д.), Я не думаю, что эта проблема должна возникнуть.

Однако ваш вопрос в конечном итоге касается MySQL:

 SELECT IF(@@global.time_zone = 'SYSTEM', @@global.system_time_zone, @@global.time_zone) AS time_zone;

 

Если MySQL установлено значение SYSTEM, его постигнет та же участь, что и tzset в PHP. Я проверил сервер друга, и часто бывает разница в час, потому что MySQL преобразует Европу/Лондон в GMT. GMT не включает BST, что является причиной многих проблем. MySQL может быть правильно настроен и использовать /etc/localtime, который будет указывать на правильный файл. Если же MySQL сообщает неправильное имя, и вы используете его для загрузки часового пояса с чем-то еще, то эти два значения, могут иметь различные значения.

Даже если вы попытаетесь включить DST, это не будет идеальным решением. Если ваш экземпляр MySQL использует SYSTEM, вы можете вместо этого посмотреть, можете ли вы преобразовать даты из этого в UTC (или дату/время PHP), что может быть тяжелым для производительности. Теоретически вы можете попытаться выполнить перебор различных вариантов, но я бы не советовал. Вы также можете попробовать установить часовой пояс в переменную сеанса, тогда MySQL будет преобразовать дату автоматически.

 

Ответ 5

На самом деле вам не нужно знать, в каком "часовом поясе" работает MySQL - вам просто нужно знать разницу с UTC .

Чтобы получить его, выполните запрос MySQL:

SELECT TIMESTAMPDIFF(HOUR, UTC_TIMESTAMP, NOW())

 

Поскольку значение NOW() основано на часовом поясе, в котором работает MySQL, разница между NOW() временем и временем в формате UTC будет считываться в часах. Затем вы можете использовать это значение для создания временной метки, например, 2016-04-15T15:52:01+01:00, которую можно использовать в DateTime::__construct().

Затем вы можете позволить PHP вычислить разницу часовых поясов между сервером приложения и базы данных, сравнив DateTime объекты. Это должно работать во всех системах.

 

Ответ 6

вы можете получить часовой пояс вашего сервера, используя

echo date_default_timezone_get();

Схожие статьи

Web

Множественные выходы из функции

Web

Преобразование строки JSON в SELECT

Firefox Quantum, что это за движок и какие у него преимущества?
Web

Firefox Quantum, что это за движок и какие у него преимущества?

Web

Проверка связи с определенным портом