ls na janela cmd dá uma hora de folga

Question

Eu tenho ls instalado no meu computador com Windows XP. Ele veio com msysgit. Eu tive um tempo e acontece que eu uso bastante mesmo no prompt do DOS. Mais de dir .

O problema é que ele me fornece carimbos de hora com um deslocamento de uma hora. Veja a data para gcc.exe, ls says 15:01, dir says 16:01:

C:\MinGW\bin>ls --full-time gcc.exe
-rwxr-xr-x    1 gaf      Administ    90112 Thu Apr 24 15:01:53 2008 gcc.exe

C:\MinGW\bin>dir gcc.exe
 Volymen i enhet C har ingen etikett.
 Volymens serienummer är 644A-83A3

 Innehåll i katalogen C:\MinGW\bin

2008-04-24  16:01            90 112 gcc.exe
               1 fil(er)              90 112 byte
           0 katalog(er)  104 458 203 136 byte ledigt

(desculpe pela linguagem estranha)

Eu posso dizer que é ls que está fazendo errado, eu verifiquei isso com arquivos recém-criados.

É bem perturbador, alguma sugestão de como eu posso resolver isso?

EDIT: mais informações adicionadas após a resposta do njd.

A alteração da variável env TZ tem efeito. Eu moro na Suécia, onde o tempo é CET no inverno, CEST no verão. Eu testei tanto UTC, CET e CEST, e chegou a resultados estranhos (para mim):

C:\Program\Git\bin>set TZ=UTC

C:\Program\Git\bin>.\date
Mon Feb 15 12:53:26 GMT 2010

C:\Program\Git\bin>set TZ=CET

C:\Program\Git\bin>.\date
Mon Feb 15 12:53:50 GMT 2010

C:\Program\Git\bin>set TZ=CEST

C:\Program\Git\bin>.\date
Mon Feb 15 12:53:59 GMT 2010

C:\Program\Git\bin>set TZ=CET+1

C:\Program\Git\bin>.\date
Mon Feb 15 11:54:27 CET 2010

C:\Program\Git\bin>set TZ=CET-1

C:\Program\Git\bin>.\date
Mon Feb 15 13:54:35 CET 2010

A configuração de TZ para CET ou CEST não tem efeito. A data exibida ainda é GMT. Parece que a string CET sozinha não tem efeito. É apenas uma string para exibição e só é levada em conta se houver um deslocamento explícito.

C:\Program\Git\bin>set TZ=FOO-1

C:\Program\Git\bin>.\date
Mon Feb 15 14:00:29 FOO 2010

C:\Program\Git\bin>set TZ=BAR-1

C:\Program\Git\bin>.\date
Mon Feb 15 14:00:42 BAR 2010

Então parece.

-1 tem o efeito correto. Mas o tempo da Suécia é UTC + 1: CET na wikipedia

Existe uma incompatibilidade na convenção, -1 em TZ é UTC + 1?

Se eu quiser deixar o sistema operacional decidir se é verão ou inverno, conforme indicado na resposta do njd, posso omitir o horário de início e de término. Eu suponho que a string correta seja TZ=CET-1CEST-2 , correto?

Não tenho certeza do que o Windows faz no verão. Se atualizar o relógio em si, a string acima não funcionará. Se ele atualizar apenas o deslocamento, isso pode funcionar. Mais ideias?

    

Answer 1

Parece que o comando ls não sabe o suficiente sobre os zomes de tempo europeus e as datas em que o CEST está em vigor.

Eu estou supondo que o 16:01 relatado por DIR foi 16:01 CEST, mas o comando ls não aplicou a hora extra para o horário de verão.

Não tenho certeza de como o msysgit (ou apenas msys) armazena informações de fuso horário: no Solaris, há arquivos zoneinfo para isso.

Se houver alguma maneira de se comunicar com suas ferramentas msysgit quando o horário de verão começar e terminar, o comando ls poderá acertar.

Talvez esta página ofereça uma pista.
Experimente brincar com configurações de ambiente como

SET TZ=CET+1CEST,M3.5.0/2,M10.5.0/2

que afirma que o CEST começa no último domingo (dia 0) de março às 2 da manhã e termina no último domingo de outubro às 2 da manhã. Isso deve lhe dar algo para trabalhar.

(Normalmente, basta indicar o fuso horário e o fuso horário do horário de verão apenas: "CET + 1CEST" e confiar no SO para saber quais devem ser as datas relevantes. Mas aqui estamos definindo as datas explicitamente.)

Eu posso ver algo semelhante acontecendo ao contrário com MSys no meu sistema:
Um arquivo reportado pelo comando DIR (e Windows Explorer) como escrito em 2008-04-18 em 12:19 (que deveria ter sido BST: GMT + 1) é mostrado por MSys ls as 13:19:06 .

Se eu brincar com as datas de fuso horário e SET TZ , embora o DST não tenha começado até no final de abril , posso alterar isso para corresponder à saída de DIR.

Mas, até onde eu sei, a regra da UE sobre o horário de verão é que começa no último domingo de março (M3.5.0 / 2) e termina no último domingo de outubro (M10.5.0 / 2). ).

Então, quando eu digito (em um shell MSys, ou no Cygwin, ou no Unix):

TZ=GMT0BST,M3.5.0/2,M10.5.0/2 ls --full-time foo

Eu devo ver a hora correta, com o DST aplicado. Na verdade, vejo 13:19, da mesma forma que quando não coloco o fuso horário de jeito nenhum.

O que me faz pensar se MSys e msysgit estão acertando, e o Windows está errado.

    

Answer 2

É irritante, mas, sim, há uma incompatibilidade na convenção, portanto, por exemplo, se o fuso horário for -3, será necessário um +3 na variável de ambiente TZ . Da documentação da biblioteca GNU C :

The offset specifies the time value you must add to the local time to get a Coordinated Universal Time value. It has syntax like [+|-]hh[:mm[:ss]]. This is positive if the local time zone is west of the Prime Meridian and negative if it is east.

Se você não especificar o período de horário de verão em TZ , a biblioteca C presumirá que não há nenhum DST. Eu acho que seria impraticável confiar em cada sistema operacional diferente para fornecer o período de DST quando faltando em TZ . Na verdade, seria muito mais fácil simplesmente obter o horário local diretamente. Então você deve especificar o período de horário de verão ao usar esse formato de configuração TZ específico.

A solução que funcionou para mim foi escrever um script em Ruby que me fornece o período do horário de verão para o meu país, onde ele é variável ao longo dos anos. Em seguida, ele exibe o formato adequado para TZ , que é definido em /etc/profile.d/ em MSYS. Este é o meu valor atual de TZ , funciona muito bem tanto para ls quanto para date :

BRT+3BRST,M10.3.0/0,M2.3.0/0

Observe, no entanto, que o tempo de execução C da Microsoft também é sensível ao valor de TZ , que pode levar a conflitos entre os aplicativos MSYS e MSVCRT . Você precisa ter o TZ não configurado ao executar aplicativos baseados em MSVCRT (como o Python) ou alguma solução melhor. Quanto às suas configurações não funcionarem, tente o valor exato acima, alterando apenas o período de horário de verão para corresponder ao seu.