Formato preferido de nomes de arquivos que incluem timestamp

Question

Como todos sabemos, "unix" pode ter qualquer coisa em um arquivo, exceto '/' e '\ 0', os sysadmins tendem a ter uma preferência muito menor, principalmente devido a nada que goste de espaços como entrada ... e um monte de coisas que têm um significado especial para ':' e '@' entre outros.

Recentemente, eu vi mais um caso em que um timestamp era usado em um nome de arquivo, e depois de jogar com diferentes formatos um pouco para torná-lo "melhor", imaginei tentar encontrar uma "melhor prática", sem ver uma que eu pensei em perguntar aqui e ver o que as pessoas pensavam.

Possíveis soluções "comuns" (p = prefixo e s = 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
   

   pros:

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

   contras:

   • A data única versão não é fácil de ler, e incluindo o tempo faz meus olhos sangrar e segundos também é apenas "lol".
   • 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
   

   pros:

   • Sem espaços.
   • Leva a conta da TZ.
   • Não é "ruim" ler por humanos (a data é apenas v. boa).
   • Pode ser gerado por $ (data --iso = {horas, minutos, segundos})

   contras:

   • scp / tar / etc. não gostará desses caracteres ':'.
   • Demora um pouco para as pessoas "normais" verem a WTF que 'T' é usada, e qual é a coisa no final:).
   • Vários 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
   

   pros:

   • Leva a conta da TZ.
   • Pode ser lido facilmente por "todos os 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 de tempo (o que significa que todo o código irá odiá-lo).
   • scp / tar / etc. não gostará desses 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
   

   pros:

   • basicamente um syslog / etc ligeiramente melhor. variante.

   contras:

   • Vários caracteres '-'.
   • Assume TZ.

5. Adoro 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
   

   pros:

   • basicamente uma variante "eu amo hífens" um pouco melhor.
   • Não há personagens estranhos.
   • Pode distinguir data / hora do prefixo / sufixo.

   contras:

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

... então qualquer pessoa quer dar uma preferência e uma razão, ou mais de uma (Por exemplo, não se preocupe com a TZ se ela for 95 +% para ficar na máquina local, mas se importar muito se não for) .

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

    

Answer 1

1. O formato ISO 8601 deve ser respeitado o máximo possível, pois é o que há de mais próximo de um padrão.
2. O 'T' não é o suficiente para impedir realmente se livrar dele.
3. Os ':' são potencialmente assassinos, então esses devem ser evitados.
4. Pelas razões mencionadas nas respostas dos outros, UTC (ou tempo 'Z') deve ser usado.
5. O ISO 8601 inclui um formato usando UTC (tempo 'Z'), que deve ser usado.
6. O ISO 8601 inclui um formato que não usa o caractere ':', que deve ser usado.

Então ... exemplos "melhores" formatos de data e hora:

1. 20120317T1748Z

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

2. 2012-03-17T1748Z

   A parte de data
   • está de acordo com a ISO 8601
   A parcela de tempo
   • está de acordo com a ISO 8601
   • a transição entre data e hora está de acordo com a ISO 8601
   • mistura o formato 'estendido' da ISO 8601 (data com hífens, hora com vírgulas) com o formato 'básico' da ISO 8601 (data sem hífens, tempo 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

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

Eu sou parcial a 1. desde que é totalmente IAW o padrão, mas os outros são próximos.

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

    

Answer 2

Eu não incluiria um fuso horário, use somente o horário universal. Se houver confusão, você pode adicionar um sufixo -UTC. Se você especificar um fuso horário, alguém pode depender dele. E haveria casos estranhos de borda em que as mudanças 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. UTC é sempre o mesmo em todos os lugares.

Acho que os hífens tornam o nome do arquivo mais legível, no sentido de facilitar a identificação do datetime dos dados do arquivo. Se você quiser incluir precisão de sub-segundo, geralmente é .nnnnn.

Eu pessoalmente não gosto do T. Usar um ponto-e-vírgula em um nome de arquivo pode afetar a interoperabilidade com outros sistemas de arquivos.

    

Answer 3

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

2. Com relação à nomenclatura do arquivo de log - eu sei, muitos não gostam disso, mas eu gosto de simplificar:

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

pros:

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

contras:

• não legível por humanos

Em máquinas onde os colegas (por qualquer motivo) precisam verificar os registros manualmente, eu fui para essa variante, girando diariamente:

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

Atenciosamente