Formato preferido de nomes de arquivos que incluem um carimbo de data / hora

Como todos sabemos que "unix" pode ter qualquer coisa em um arquivo, exceto '/' e '\ 0', os administradores de sistemas, no entanto, tendem a ter uma preferência muito menor, principalmente devido a nada gostar de espaços como entrada ... e várias coisas tendo um significado especial para ':' e '@' entre outros.

Recentemente, vi outro caso em que um carimbo de data e hora era usado em um nome de arquivo e, depois de jogar um pouco com diferentes formatos para torná-lo "melhor", imaginei que tentaria encontrar uma "melhor prática", sem ver uma que eu imaginava. Gostaria de perguntar aqui e ver o que as pessoas pensavam.

Possíveis soluções "comuns" (p = prefixo es = sufixo):

1. syslog / logrotate / DNS como formato:

   p-%Y%m%d-suffix = prefix-20110719-s
   p-%Y%m%d%H%M-suffix = prefix-201107191732-s
   p-%Y%m%d%H%M%S-suffix = prefix-20110719173216-s
   

   profissionais:

   • É "comum", então "bom o suficiente" pode ser melhor que "melhor".
   • Sem personagens estranhos.
   • Fácil de distinguir o "blob de data / hora" de todo o resto.

   contras:

   • A versão apenas para data não é fácil de ler, e incluir o tempo faz meus olhos sangrarem e segundos também são apenas "risos".
   • Assume TZ.

2. Formato ISO-8601-

   p-%Y-%m-%d-s = p-2011-07-19-s
   p-%Y-%m-%dT%H:%M%z-s = p-2011-07-19T17:32-0400-s
   p-%Y-%m-%dT%H:%M:%S%z-s = p-2011-07-19T17:32:16-0400-s
   p-%Y-%m-%dT%H:%M:%S%z-s = p-2011-07-19T23:32:16+0200-s
   

   profissionais:

   • Sem espaços.
   • Leva TZ em consideração.
   • Não é "ruim" para ser lido por humanos (a data é apenas v. Boa).
   • Pode ser gerado por $ (data --iso = {horas, minutos, segundos})

   contras:

   • scp / tar / etc. não vai gostar dos caracteres ':'.
   • Demora um pouco para as pessoas "normais" verem o WTF para o qual 'T' é, e para que servem as coisas no final :).
   • Muitos caracteres '-'.

3. formato rfc-3339

   p-%Y-%m-%d-s = p-2011-07-19-s
   p-%Y-%m-%d %H:%M%:z-s = p-2011-07-19 17:32-04:00-s
   p-%Y-%m-%d %H:%M:%S%:z-s = p-2011-07-19 17:32:16-04:00-s
   p-%Y-%m-%d %H:%M:%S%:z-s = p-2011-07-19 23:32:16+02:00-s
   

   profissionais:

   • Leva TZ em consideração.
   • Pode ser facilmente lido por "todos os seres humanos".
   • Pode distinguir data / hora do prefixo / sufixo.
   • Algumas das opções acima podem ser geradas com $ (date --iso = {hours, seconds})

   contras:

   • Tem espaços nas versões temporais (o que significa que todo o código o odiará).
   • scp / tar / etc. não vai gostar dos caracteres ':'.

4. Eu amo hífens:

   p-%Y-%m-%d-s = p-2011-07-19-s
   p-%Y-%m-%d-%H-%M-s = p-2011-07-19-17-32-s
   p-%Y-%m-%d-%H-%M-%S-s = p-2011-07-19-23-32-16-s
   

   profissionais:

   • basicamente um syslog / etc ligeiramente melhor. variante.

   contras:

   • Muitos caracteres '-'.
   • Assume TZ.

5. Eu amo hífens, com extensões:

   p.%Y-%m-%d.s = p.2011-07-19.s
   p.%Y-%m-%d.%H-%M.s = p.2011-07-19.17-32.s
   p.%Y-%m-%d.%H-%M-%S.s = p.2011-07-19.23-32-16.s
   

   profissionais:

   • basicamente uma variante "Eu amo hífens" um pouco mais agradável.
   • Sem personagens estranhos.
   • Pode distinguir data / hora do prefixo / sufixo.

   contras:

   • Usando '.' aqui é um pouco não tradicional.
   • Assume TZ.

... para que alguém queira dar uma preferência e uma razão, ou mais de uma (por exemplo, não se importe com a TZ se 95% + permanecer na máquina local, mas se importe muito se não for).

Ou, obviamente, algo que não está na lista acima.

1. O formato ISO 8601 deve ser respeitado o máximo possível, pois é a coisa mais próxima que existe de um padrão.
2. O 'T' não é uma pedra de tropeço suficiente para realmente garantir a sua eliminação.
3. Os ':' são potencialmente assassinos, portanto esses devem ser evitados.
4. Pelas razões mencionadas nas respostas de outras pessoas, o UTC (ou o horário 'Z') deve ser usado.
5. A ISO 8601 inclui um formato usando UTC (hora 'Z'), que deve ser usado.
6. A ISO 8601 inclui um formato que não usa o caractere ':', que deve ser usado.

Então ... experimente os melhores formatos de data e hora:

1. 20120317T1748Z

   • 100% de acordo com a ISO 8601
   • apenas caracteres alfanuméricos (muito compatíveis com o administrador de sistemas)
   • não é o mais rápido de ler, mas certamente legível pelo leigo

2. 2012-03-17T1748Z

   • parte da data está de acordo com a ISO 8601
   • parte do tempo está de acordo com a ISO 8601
   • A transição entre data e hora está de acordo com a ISO 8601
   • combina o formato 'estendido' da ISO 8601 (data com hífens, hora com dois pontos) com o formato 'básico' da ISO 8601 (data sem hífens, hora sem dois pontos), o que provavelmente não está certo
   • adiciona o caractere '-' (vs 1.)
   • um pouco mais fácil para o leigo ler (vs 1.)

3. 2012-03-17--1748Z

   • parte da data está de acordo com a ISO 8601
   • parte do tempo está de acordo com a ISO 8601
   • transição entre data e hora não está de acordo com a ISO 8601
   • combina o formato ISO 8601 'estendido' com o formato ISO 8601 'básico'
   • um pouco mais fácil para o leigo ler (vs 1. e 2.)
   • sem novos personagens (vs 2.)

Sou parcial a 1., pois é totalmente IAW o padrão, mas os outros estão próximos.

Nota :: Adicione segundos conforme necessário, é claro. ... e sim, com ou sem segundos (ou mesmo minutos) é tudo IAW ISO 8601. :)

Eu não incluiria um fuso horário, apenas usaria o horário universal. Se houver confusão, você poderá adicionar um sufixo -UTC. Se você especificar um fuso horário, alguém poderá depender dele. E haveria casos extremos estranhos em que as alterações de horário de verão ou as mudanças de horário de verão causam estragos em algum processamento, ou o processamento é diferente em alguns sistemas porque sua configuração de horário de verão não está atualizada. O UTC é sempre o mesmo em todo lugar.

Eu acho que os hífens tornam o nome do arquivo mais legível, no sentido de facilitar o discernimento da data e hora dos dados do arquivo. Se você deseja incluir precisão de menos de um segundo, geralmente é .nnnnn.

Eu pessoalmente não gosto do T. Usar dois pontos em um nome de arquivo pode afetar a interoperabilidade com outros sistemas de arquivos.

1. Eu também não incluiria fusos horários. Seus scripts / ferramentas que processam os logs devem saber sobre isso. Também em relação às alterações no horário de verão / inverno - eu recomendo manter o servidor sempre fixo na UTC o tempo todo. Uma diferença repentina entre o fuso horário do servidor base e o fuso horário (inalterado) de um banco de dados em execução pode levar a dores de cabeça ;-).

2. Em relação à nomeação de arquivos de log - eu sei, muitos não gostam, mas eu gosto de simplificar:

p-%s-type.log = p-1311116459-type.log

profissionais:

• denominador comum
• muito fácil de usar em scripts adicionais

contras:

• não legível por humanos

Nas máquinas em que colegas (por qualquer motivo) precisam verificar os logs manualmente, eu fui para essa variante, girando diariamente:

p-%Y-%m-%d-type.log = p-2011-07-20-type.log

Cumprimentos