Nuestro grupo de redactores ha estado horas buscando la solución a tu búsqueda, te brindamos la respuestas por eso deseamos resultarte de gran apoyo.
Solución:
Ese último ejemplo debería haberte aclarado las cosas: zonas horarias.
$ TZ=UTC date -d "2019-01-19T05:00:00Z - 2 hours" +%Y-%m-%d_%H:%M:%S
2019-01-19_03:00:00
$ TZ=Asia/Colombo date -d "2019-01-19T05:00:00Z - 2 hours" +%Y-%m-%d_%H:%M:%S
2019-01-19_08:30:00
Como la salida varía claramente según la zona horaria, sospecho que se tomó un valor predeterminado no obvio durante un tiempo string sin una zona horaria especificada. Probando un par de valores, parece ser UTC-05: 00, aunque no estoy seguro de cuál es.
$ TZ=UTC date -d "2019-01-19T05:00:00 - 2 hours" +%Y-%m-%d_%H:%M:%S%Z
2019-01-19_08:00:00UTC
$ TZ=UTC date -d "2019-01-19T05:00:00Z - 2 hours" +%Y-%m-%d_%H:%M:%S%Z
2019-01-19_03:00:00UTC
$ TZ=UTC date -d "2019-01-19T05:00:00" +%Y-%m-%d_%H:%M:%S%Z
2019-01-19_05:00:00UTC
Solo se usa cuando se realiza aritmética de fechas.
Parece que el problema aquí es que - 2 hours es no tomado como aritmética, pero como un especificador de zona horaria:
# TZ=UTC date -d "2019-01-19T05:00:00 - 2 hours" +%Y-%m-%d_%H:%M:%S%Z --debug
date: parsed datetime part: (Y-M-D) 2019-01-19 05:00:00 UTC-02
date: parsed relative part: +1 hour(s)
date: input timezone: parsed date/time string (-02)
date: using specified time as starting value: '05:00:00'
date: starting date/time: '(Y-M-D) 2019-01-19 05:00:00 TZ=-02'
date: '(Y-M-D) 2019-01-19 05:00:00 TZ=-02' = 1547881200 epoch-seconds
date: after time adjustment (+1 hours, +0 minutes, +0 seconds, +0 ns),
date: new time = 1547884800 epoch-seconds
date: timezone: TZ="UTC" environment value
date: final: 1547884800.000000000 (epoch-seconds)
date: final: (Y-M-D) 2019-01-19 08:00:00 (UTC)
date: final: (Y-M-D) 2019-01-19 08:00:00 (UTC+00)
2019-01-19_08:00:00UTC
Entonces, no solo no se está haciendo aritmética, parece haber una horario de verano Ajuste de 1 hora en el tiempo, lo que nos lleva a un tiempo un tanto sin sentido.
Esto también es válido para la adición:
# TZ=UTC date -d "2019-01-19T05:00:00 + 5:30 hours" +%Y-%m-%d_%H:%M:%S%Z --debug
date: parsed datetime part: (Y-M-D) 2019-01-19 05:00:00 UTC+05:30
date: parsed relative part: +1 hour(s)
date: input timezone: parsed date/time string (+05:30)
date: using specified time as starting value: '05:00:00'
date: starting date/time: '(Y-M-D) 2019-01-19 05:00:00 TZ=+05:30'
date: '(Y-M-D) 2019-01-19 05:00:00 TZ=+05:30' = 1547854200 epoch-seconds
date: after time adjustment (+1 hours, +0 minutes, +0 seconds, +0 ns),
date: new time = 1547857800 epoch-seconds
date: timezone: TZ="UTC" environment value
date: final: 1547857800.000000000 (epoch-seconds)
date: final: (Y-M-D) 2019-01-19 00:30:00 (UTC)
date: final: (Y-M-D) 2019-01-19 00:30:00 (UTC+00)
2019-01-19_00:30:00UTC
Depurando un poco más, el análisis parece ser: 2019-01-19T05:00:00 - 2 (-2 siendo la zona horaria), y hours (= 1 hora), con una adición implícita. Es más fácil ver si usa minutos en su lugar:
# TZ=UTC date -d "2019-01-19T05:00:00 - 2 minutes" +%Y-%m-%d_%H:%M:%S%Z --debug
date: parsed datetime part: (Y-M-D) 2019-01-19 05:00:00 UTC-02
date: parsed relative part: +1 minutes
date: input timezone: parsed date/time string (-02)
date: using specified time as starting value: '05:00:00'
date: starting date/time: '(Y-M-D) 2019-01-19 05:00:00 TZ=-02'
date: '(Y-M-D) 2019-01-19 05:00:00 TZ=-02' = 1547881200 epoch-seconds
date: after time adjustment (+0 hours, +1 minutes, +0 seconds, +0 ns),
date: new time = 1547881260 epoch-seconds
date: timezone: TZ="UTC" environment value
date: final: 1547881260.000000000 (epoch-seconds)
date: final: (Y-M-D) 2019-01-19 07:01:00 (UTC)
date: final: (Y-M-D) 2019-01-19 07:01:00 (UTC+00)
2019-01-19_07:01:00UTC
Entonces, bueno, se está haciendo aritmética de fechas, pero no la que pedimos. ¯ (ツ) / ¯
Funciona correctamente cuando convierte la fecha de entrada a ISO 8601 primero:
$ date -d "$(date -Iseconds -d "2018-12-10 00:00:00") - 5 hours - 20 minutes - 5 seconds"
So 9. Dez 18:39:55 CET 2018
TLDR: Esto no es un error. Acaba de encontrar uno de los comportamientos sutiles pero documentados de date. Al realizar aritmética de tiempos con date, use un formato independiente de la zona horaria (como la hora de Unix) o lea muy cuidadosamente la documentación para saber cómo usar correctamente este comando.
ÑU date utiliza la configuración de su sistema (el TZ variable de entorno o, si no está configurada, los valores predeterminados del sistema) para determinar la zona horaria de la fecha alimentada con el -d/--date opción y la fecha informada por el +format argumento. los --date La opción también le permite anular la zona horaria para su propio argumento de opción, pero no anula la zona horaria de +format. Esa es la raíz de la confusión, en mi humilde opinión.
Teniendo en cuenta que mi zona horaria es UTC-6, compare los siguientes comandos:
$ date -d '1970-01-01 00:00:00' '+Normal: %F %T %:z%nUnix: %s'
Normal: 1970-01-01 00:00:00 -06:00
Unix: 21600
$ date -d '1970-01-01 00:00:00 UTC' '+Normal: %F %T %:z%nUnix: %s'
Normal: 1969-12-31 18:00:00 -06:00
Unix: 0
$ TZ='UTC0' date -d '1970-01-01 00:00:00 UTC' '+Normal: %F %T %:z%nUnix: %s'
Normal: 1970-01-01 00:00:00 +00:00
Unix: 0
El primero usa mi zona horaria para ambos -d y +format. El segundo usa UTC para -d pero mi zona horaria para +format. El tercero usa UTC para ambos.
Ahora, compare las siguientes operaciones simples:
$ date -d '1970-01-01 00:00:00 UTC +1 day' '+Normal: %F %T %:z%nUnix: %s'
Normal: 1970-01-01 18:00:00 -06:00
Unix: 86400
$ TZ='UTC0' date -d '1970-01-01 00:00:00 UTC +1 day' '+Normal: %F %T %:z%nUnix: %s'
Normal: 1970-01-02 00:00:00 +00:00
Unix: 86400
Incluso si la hora de Unix me dice lo mismo, la hora “Normal” difiere debido a mi propia zona horaria.
Si quisiera hacer la misma operación pero usando exclusivamente mi zona horaria:
$ TZ='CST+6' date -d '1970-01-01 00:00:00 -06:00 +1 day' '+Normal: %F %T %:z%nUnix: %s'
Normal: 1970-01-02 00:00:00 -06:00
Unix: 108000
Si haces scroll puedes encontrar las referencias de otros usuarios, tú asimismo eres capaz mostrar el tuyo si lo crees conveniente.