¿Cómo puedo obtener la zona horaria del servidor local sin depender de php.ini u otros archivos de configuración?¿Cómo puedo obtener la zona horaria del servidor local?
Estoy buscando una salida similar a la salida de date('e'). p.ej. "UTC", "GMT" o "Atlántico/Azores".
Necesito saber esto para poder conocer la zona horaria de MySQL.
Si estás en * nix, llama a la date del sistema utilizando popen:
popen("date +%Z");
Para Windows: WMi http://pastebin.com/qhmvEvP0 – user956584
Si estás usando una plataforma de alojamiento basado en Linux/Unix, se puede utilizar la salida del comando date con el formateador "tiempo alfabético zona abreviatura" como tal:
$systemTimeZone = system('date +%Z');
sin embargo, cabe señalar que no se debe necesariamente apoyarse en la zona horaria del sistema y que en su lugar debe usar date_default_timezone_set (o el date.timezone php.in i setting) para establecer la zona horaria requerida.
edito mi pregunta para que pueda entender lo que quiero hacer – dvdx
@dvdx ¿Para qué sirve una cadena como "América/Nueva York"? –
porque America/New York mostrará uno de los MUCHOS de la lista de formatos de zona horaria compatibles que se encuentran aquí: http://www.php.net/manual/en/timezones.php – SoLoGHoST
en Linux/Unix yo uso
shell_exec("date +%Z");
En realidad no es necesario saber qué "zona horaria" MySQL se está ejecutando en - simplemente hay que saber la diferencia a UTC.
Para conseguir que simplemente puede pedir a MySQL:
SELECT TIMESTAMPDIFF(HOUR, UTC_TIMESTAMP, NOW())
Como el valor de NOW() se basa en la zona horaria de MySQL se está ejecutando en, que leerá la diferencia entre NOW() y la hora UTC, en horas. A continuación, puede usar ese valor para crear una marca de tiempo completa como 2016-04-15T15:52:01+01:00 que se puede usar en DateTime::__construct().
A continuación, puede dejar que PHP preocupación acerca de la diferencia entre las zonas horarias de los servidores de aplicaciones y bases de datos mediante la comparación de objetos DateTime ... y que debe trabajo en todos los sistemas.
Esto no da la zona horaria real, solo el efecto de la zona horaria Algunas zonas horarias se superponen especialmente con horario de verano o cuando se cambian. – jgmjgm
@jgmjgm - punto justo, simplemente no estaba convencido de que el OP * realmente * necesita algo como la cadena 'GMT' si ves lo que quiero decir ... no lo necesitas para ningún tipo de cálculos que simplemente te da una cadena más legible Creo que estaba tratando de proporcionar una solución alternativa a lo que sospechaba que era el problema subyacente en lugar de responder la pregunta "tal como estaba" ... fue hace un tiempo;) – CD001
puede obtener la zona horaria de su servidor de esta manera. echo date_default_timezone_get();
Estas respuestas no son buenas. No sé de una manera portátil de hacerlo.
Para Linux aquí es una opción: https://bojanz.wordpress.com/2014/03/11/detecting-the-system-timezone-php/
La fecha de soluciones que otros están enumerando podría no ser exacta ya que el problema está en Linux y la utilidad de la fecha (gnuutils, gnulib) heredará el mismo problema.
Si configuro la zona horaria en Europa/Berlín y luego pregunto la fecha de la zona horaria, me dará CET.
La manera de obtener la zona horaria en Linux es así:
#include <time.h>
#include <stdio.h>
extern char *tzname[2];
extern long timezone;
extern int daylight;
void main() {
tzset();
printf(tzname[0]);
}
El problema es que los archivos de zona no incluyen su nombre, sólo la lista de zonas horarias de los padres o algo por el estilo.
CET no es lo mismo que la zona de Europa/Berlín. Si pongo CET, las fechas pueden calcularse incorrectamente. A veces, esto no importará ya que algunos países han estado utilizando una zona horaria durante décadas, pero ocasionalmente puede ser importante.
Usando zdump aquí es un diff entre el CET y Europa/Berlín:
> 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
Algunos de ellos ni siquiera podría ser importante si usted está usando un unixtime pero se puede ver claramente aquí que en los años 70 algunos lo . Es probable que haya otras zonas horarias con cambios mucho más recientes que se rompan utilizando el resultado de tzset. Para muchos, esto sería un problema adicional, pero si te afecta, el resultado probablemente no sea agradable.
No sé cuál es la convención para Windows o si existe el mismo problema. Hay una excepción a este problema. Si la zona horaria de su sistema es una raíz (como GMT, UTC, CET, etc.) entonces no creo que este problema ocurra.
Sin embargo su pregunta es en última instancia sobre MySQL:
SELECT IF(@@global.time_zone = 'SYSTEM', @@global.system_time_zone, @@global.time_zone) AS time_zone;
Si se establece en el sistema sino que también van a sufrir el mismo destino que PHP y tzset. Comprobé el servidor de un amigo y a menudo hay una diferencia de una hora porque MySQL convierte Europa/Londres en GMT. GMT no incluye BST, que es la causa de muchos problemas. Internamente MySQL podría estar bien porque todavía está usando/etc/localtime que apuntará al archivo correcto incluso si MySQL está informando el nombre incorrecto, pero si toma ese nombre incorrecto y lo usa para cargar la zona horaria con otra cosa, puede que los dos no tener la misma zona horaria
Incluso si ha intentado incluir DST, no sería una solución perfecta. Si su instancia de MySQL está utilizando SYSTEM, en su lugar puede querer ver si puede convertir las fechas a UTC (o la fecha/hora de PHP), lo que puede ser doloroso para el rendimiento. En teoría, podrías intentar la detección de fuerza bruta, pero no te lo aconsejaría. También puede intentar configurar la zona horaria en la variable de sesión y MySQL puede convertirse automáticamente, pero asegúrese de estar seguro y siempre RTM (si eso no funciona, utilice la fuente).
¿En qué sistema operativo desea hacer esto? – alexn