Formato preferido de nombres de archivo que incluye una marca de tiempo

Como todos sabemos, "unix" puede tener cualquier cosa en un archivo excepto '/' y '\ 0', sin embargo, los administradores de sistemas tienden a tener una preferencia mucho menor, principalmente debido a que no le gustan los espacios como entrada ... y un montón de cosas que tienen un significado especial para ':' y '@' entre otros.

Recientemente había visto otro caso en el que se usaba una marca de tiempo en un nombre de archivo, y después de jugar un poco con diferentes formatos para hacerlo "mejor", pensé que trataría de encontrar una "mejor práctica", sin ver uno que pensé Solo preguntaría aquí y vería qué pensaba la gente.

Posibles soluciones "comunes" (p = prefijo ys = sufijo):

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:

   • Es "común", por lo que "lo suficientemente bueno" podría ser mejor que "mejor".
   • No hay personajes extraños.
   • Fácil de distinguir el "blob de fecha / hora" de todo lo demás.

   contras:

   • La versión de fecha única no es fácil de leer, e incluir el tiempo hace que mis ojos sangren y los segundos también son solo "jajaja".
   • Asume 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:

   • No hay espacios.
   • Toma en cuenta TZ.
   • Es "no está mal" que los humanos lo lean (la fecha solo es muy buena).
   • Puede ser generado por $ (fecha --iso = {horas, minutos, segundos})

   contras:

   • scp / tar / etc. no le gustarán esos caracteres ':'.
   • Las personas "normales" tardan un poco en ver WTF para lo que es 'T', y para qué sirve la cosa al final :).
   • Un montón de 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:

   • Toma en cuenta TZ.
   • Puede ser leído fácilmente por "todos los humanos".
   • Puede distinguir fecha / hora del prefijo / sufijo.
   • Algunos de los anteriores se pueden generar con $ (fecha --iso = {horas, segundos})

   contras:

   • Tiene espacios en las versiones de tiempo (lo que significa que todo el código lo odiará).
   • scp / tar / etc. no le gustarán esos caracteres ':'.

4. Me encantan los guiones:

   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:

   • básicamente un syslog / etc un poco mejor variante.

   contras:

   • Un montón de caracteres '-'.
   • Asume TZ.

5. Me encantan los guiones, con extensiones:

   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:

   • Básicamente, una variante un poco más agradable "Amo guiones".
   • No hay personajes extraños.
   • Puede distinguir fecha / hora del prefijo / sufijo.

   contras:

   • Utilizando '.' Aquí es algo no tradicional.
   • Asume TZ.

... así que cualquiera quiere dar una preferencia y una razón, o más de una (por ejemplo, no me importa TZ si es 95 +% para mantener la máquina local, pero me importa mucho si no lo es).

O, obviamente, algo que no está en la lista anterior.

1. El formato ISO 8601 debe respetarse lo más posible, ya que es lo más parecido a un estándar.
2. La 'T' no es un obstáculo suficiente para justificar realmente deshacerse de ella.
3. Los ':' son potencialmente asesinos, por lo que deben evitarse.
4. Por las razones mencionadas en las respuestas de otros, se debe usar UTC (o tiempo "Z").
5. ISO 8601 incluye un formato que usa UTC (tiempo 'Z'), que debe usarse.
6. ISO 8601 incluye un formato que no usa el carácter ':', que debe usarse.

Entonces ... muestra 'mejores' formatos de fecha y hora:

1. 20120317T1748Z

   • 100% de acuerdo con ISO 8601
   • solo caracteres alfanuméricos (muy amigable para los administradores de sistemas)
   • no es el más rápido de leer, pero ciertamente legible por el laico

2. 2012-03-17T1748Z

   • la porción de la fecha está de acuerdo con ISO 8601
   • parte de tiempo está de acuerdo con ISO 8601
   • La transición entre la fecha y la hora está de acuerdo con ISO 8601
   • mezcla el formato 'extendido' ISO 8601 (fecha con guiones, hora con dos puntos) con el formato 'básico' ISO 8601 (fecha sin guiones, hora sin dos puntos), que probablemente no sea del todo correcto
   • agrega el carácter '-' (vs 1.)
   • un poco más fácil para el lego leer (vs 1.)

3. 2012-03-17--1748Z

   • la porción de la fecha está de acuerdo con ISO 8601
   • parte de tiempo está de acuerdo con ISO 8601
   • la transición entre fecha y hora no está de acuerdo con ISO 8601
   • mezcla el formato 'extendido' ISO 8601 con el formato 'básico' ISO 8601
   • un poco más fácil para el laico de leer (vs 1. y 2.)
   • sin nuevos personajes (vs 2.)

Soy parcial a 1. ya que es completamente IAW el estándar, pero los otros están cerca.

Nota :: Agregue segundos según sea necesario, por supuesto. ... y sí, con o sin segundos (o incluso minutos) es todo IAW ISO 8601. :)

No incluiría una zona horaria, solo usaría la hora universal. Si puede haber confusión, puede agregar un sufijo -UTC. Si especifica una zona horaria, alguien puede depender de ella. Y habría casos extraños en los que los cambios de DST o los cambios de DST causan estragos en algunos procesos, o el procesamiento es diferente en algunos sistemas porque su configuración de DST no está actualizada. UTC es siempre el mismo en todas partes.

Creo que los guiones hacen que el nombre del archivo sea más legible, en el sentido de que hace que sea más fácil discernir la fecha y hora de los datos del archivo. Si desea incluir precisión por debajo del segundo, eso generalmente es .nnnnn.

Personalmente, no me gusta la T. El uso de dos puntos en un nombre de archivo puede afectar la interoperabilidad con otros sistemas de archivos.

1. Yo tampoco incluiría zonas horarias. Sus scripts / herramientas que procesan los registros deben saberlo. También con respecto a los cambios de horario de verano / invierno: recomiendo mantener su servidor siempre fijo en UTC todo el tiempo. Una diferencia repentina entre la zona horaria del servidor base y una zona horaria (sin cambios) de una base de datos que se ejecuta en ella puede provocar dolores de cabeza ;-).

2. Con respecto a la nomenclatura del archivo de registro: lo sé, a muchos no les gusta, pero me gusta que sea simple:

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

pros:

• común denominador
• muy fácil de usar en secuencias de comandos adicionales

contras:

• no legible por humanos

En las máquinas donde los colegas (por cualquier razón) necesitan verificar los registros manualmente, elegí esta variante, rotando diariamente:

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

Atentamente