Início / unix / Perguntas / 497639
Accepted
confetti
Asked: 2019-01-31 00:30:29 +0800 CST

Subtrair o tempo usando data e bash

  • 772

Todas as outras questões na rede SE tratam de cenários em que a data é assumida como now( Q ) ou onde apenas uma data é especificada ( Q ).

O que eu quero fazer é fornecer uma data e hora e, em seguida, subtrair uma hora disso.
Aqui está o que eu tentei primeiro:

date -d "2018-12-10 00:00:00 - 5 hours - 20 minutes - 5 seconds"

Isso resulta em 2018-12-10 06:39:55- Adicionou 7 horas. Em seguida, subtraiu 20:05 minutos.

Depois de ler a página mane de , pensei ter corrigido com isso:infodate

date -d "2018-12-10T00:00:00 - 5 hours - 20 minutes - 5 seconds"

Mas, mesmo resultado. De onde ele tira as 7 horas?

Tentei outras datas também porque pensei que talvez tivéssemos 7200 segundos bissextos naquele dia, quem sabe lol. Mas mesmos resultados.

Mais alguns exemplos:

$ date -d "2018-12-16T00:00:00 - 24 hours" +%Y-%m-%d_%H:%M:%S
2018-12-17_02:00:00

$ date -d "2019-01-19T05:00:00 - 2 hours - 5 minutes" +%Y-%m-%d_%H:%M:%S
2019-01-19_08:55:00

Mas aqui torna-se interessante. Se eu omitir o tempo na entrada, funciona bem:

$ date -d "2018-12-16 - 24 hours" +%Y-%m-%d_%H:%M:%S
2018-12-15_00:00:00

$ date -d "2019-01-19 - 2 hours - 5 minutes" +%Y-%m-%d_%H:%M:%S
2019-01-18_21:55:00

$ date --version
date (GNU coreutils) 8.30

o que estou perdendo?

Atualização: adicionei um Zno final e isso mudou o comportamento:

$ date -d "2019-01-19T05:00:00Z - 2 hours" +%Y-%m-%d_%H:%M:%S
2019-01-19_04:00:00

Eu ainda estou confuso embora. Não há muito sobre isso na página de informações do GNU sobre data.

Suponho que este seja um problema de fuso horário, mas citando o The Calendar Wiki na ISO 8601 :

Se nenhuma informação de relação UTC for fornecida com uma representação de hora, assume-se que a hora está na hora local.

Que é o que eu quero. Minha hora local também está definida corretamente. Não sei por que date mexeria com o fuso horário neste caso simples de eu fornecer um datetime e querer subtrair algo dele. Não deveria subtrair as horas da string de data primeiro? Mesmo que ele converta para uma data primeiro e depois faça a subtração, se eu deixar de fora qualquer subtração, recebo exatamente o que quero:

$ date -d "2019-01-19T05:00:00" +%Y-%m-%d_%H:%M:%S
2019-01-19_05:00:00

Então, se isso realmente for um problema de fuso horário, de onde vem essa loucura?

date gnu

5 respostas

  1. Best Answer

    Esse último exemplo deve ter esclarecido as coisas para você: fusos horários .

    $ 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 a saída varia claramente de acordo com o fuso horário, suspeito que algum padrão não óbvio seja usado para uma string de tempo sem um fuso horário especificado. Testando alguns valores, parece ser UTC-05:00 , embora eu não tenha certeza do que é isso.

    $ 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

    É usado apenas ao realizar aritmética de data.

    Parece que o problema aqui é que não- 2 hours é tomado como aritmética, mas como um especificador de fuso horário :

    # 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

    Portanto, não apenas não há aritmética sendo feita, mas parece haver um ajuste de 1 hora no horário de verão , levando a um tempo um tanto sem sentido para nós.

    Isso também vale para adição:

    # 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 um pouco mais, a análise parece ser: 2019-01-19T05:00:00 - 2( -2sendo o fuso horário) e hours(= 1 hora), com uma adição implícita. Fica mais fácil ver se você usar minutos em vez disso:

    # 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

    Então, bem, a aritmética de datas está sendo feita, mas não a que pedimos. ¯\(ツ)/¯

    • 28

  2. Funciona corretamente quando você converte a data de entrada para ISO 8601 primeiro:

    $ 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
    • 8

  3. O GNU datesuporta aritmética de data simples, embora os cálculos de tempo de época, como mostrado na resposta do @sudodus, sejam às vezes mais claros (e mais portáteis).

    O uso de +/- quando não há fuso horário especificado no carimbo de data/hora aciona uma tentativa de corresponder a um fuso horário a seguir, antes que qualquer outra coisa seja analisada.

    Aqui está uma maneira de fazer isso, use "ago" em vez de "-":

    $ date -d "2018-12-10 00:00:00 5 hours ago 20 minutes ago 5 seconds ago"
Sun Dec  9 18:39:55 GMT 2018

    ou

    $ date -d "2018-12-10 00:00:00Z -5 hours -20 minutes -5 seconds"
Sun Dec  9 18:39:55 GMT 2018

    (Embora você não possa usar "Z" arbitrariamente, ele funciona na minha zona, mas isso o torna um carimbo de data/hora da zona UTC/GMT - use sua própria zona ou %z/%Z anexando ${TZ:-$(date +%z)}ao carimbo de data/hora.)

    Adicionando termos de tempo extra destes formulários ajusta o tempo:

    • "5 horas atrás" subtrair 5 horas
    • "4 horas" adicionar (implícito) 4 horas
    • "3 horas a partir de agora" adicionar (explícito) 3 horas (não suportado em versões mais antigas)

    Muitos ajustes complexos, em qualquer ordem, podem ser usados ​​(embora termos relativos e variáveis ​​como "14 semanas a partir da última segunda-feira" estejam pedindo problemas ;-)

    (Tem outra pequena armadilha de urso aqui também, datesempre dará uma data válida, então date -d "2019-01-31 1 month"dá 2019-03-03, assim como "próximo mês")

    Dada a grande variedade de formatos de hora e data que são suportados, a análise de fuso horário é necessariamente desleixada: pode ser um sufixo de uma ou várias letras, um deslocamento de hora ou hora:minuto, um nome "América/Denver" (ou mesmo um nome de arquivo no caso da TZvariável).

    Sua 2018-12-10T00:00:00versão não funciona porque "T" é apenas um delimitador, não um fuso horário, adicionar "Z" no final faz com que funcione (sujeito à correção da zona escolhida) conforme o esperado também.

    Veja: https://www.gnu.org/software/tar/manual/html_node/Date-input-formats.html e em particular a seção 7.7.

    • 6

  4. TLDR: Isso não é um bug. Você acabou de encontrar um dos comportamentos sutis, mas documentados do date. Ao realizar aritmética de tempo com date, use um formato independente de fuso horário (como a hora do Unix) ou leia com muito cuidado a documentação para saber como usar corretamente este comando.

    O GNU dateusa as configurações do seu sistema (a TZvariável de ambiente ou, se não definida, o padrão do sistema) para determinar o fuso horário da data alimentada com a opção -d/ --datee a data relatada pelo +formatargumento. A --dateopção também permite que você substitua o fuso horário por seu próprio argumento de opção, mas não substitui o fuso horário de +format. Essa é a raiz da confusão, IMHO.

    Considerando que meu fuso horário é UTC-6, compare os seguintes 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

    O primeiro usa meu fuso horário para -de +format. O segundo usa UTC para -dmas meu fuso horário para +format. O terceiro usa UTC para ambos.

    Agora, compare as seguintes operações 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

    Mesmo que o horário do Unix esteja me dizendo a mesma coisa, o horário "Normal" difere por causa do meu próprio fuso horário.

    Se eu quisesse fazer a mesma operação, mas usando exclusivamente meu fuso horário:

    $ 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
    • 5

  5. Esta solução é fácil de entender, mas um pouco mais complicada, então eu a mostro como um shellscript.

    • converter para 'segundos desde 1970-01-01 00:00:00 UTC'
    • adicionar ou subtrair a diferença
    • converter de volta para um formato legível por humanos com uma datelinha de comando final

    Shellscript:

    #!/bin/bash

startdate="2018-12-10 00:00:00"

ddif="0"          # days
diff="-5:-20:-5"  # hours:minutes:seconds

#-----------------------------------------------------------------------------

ss1970in=$(date -d "$startdate" "+%s")  # seconds since 1970-01-01 00:00:00 UTC
printf "%11s\n" "$ss1970in"

h=${diff%%:*}
m=${diff#*:}
m=${m%:*}
s=${diff##*:}
difs=$(( (((ddif*24+h)*60)+m)*60+s ))
printf "%11s\n" "$difs"

ss1970ut=$((ss1970in + difs))  # add/subtract the time difference
printf "%11s\n" "$ss1970ut"

date -d "@$ss1970ut" "+%Y-%m-%d %H:%M:%S"
    • 1

relate perguntas