Formato preferito di nomi di file che includono un timestamp

Come tutti sappiamo "unix" può contenere qualsiasi cosa in un file tranne '/' e '\ 0', tuttavia gli amministratori di sistema tendono ad avere una preferenza molto più piccola, principalmente a causa del fatto che non piacciono gli spazi come input ... e un mucchio di cose che hanno un significato speciale per ':' e '@' tra gli altri.

Di recente ho visto un altro caso in cui un timestamp è stato utilizzato in un nome file e dopo aver giocato un po 'con formati diversi per renderlo "migliore", ho pensato che avrei cercato di trovare una "best practice", non vedendo quello che ho immaginato Vorrei solo chiedere qui e vedere cosa pensava la gente.

Possibili soluzioni "comuni" (p = prefisso e s = suffisso):

1. formato syslog / logrotate / DNS:

   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
   

   professionisti:

   • È "comune", quindi "abbastanza buono" potrebbe essere migliore di "migliore".
   • Nessun personaggio strano.
   • Facile distinguere il "blob data / ora" da tutto il resto.

   contro:

   • La sola versione della data non è facile da leggere, e includendo il tempo mi fa sanguinare gli occhi e anche i secondi sono solo "lol".
   • Presuppone 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
   

   professionisti:

   • No spazi.
   • Tiene conto di TZ.
   • È "non male" leggere dagli umani (solo la data è v. Buona).
   • Può essere generato da $ (data --iso = {ore, minuti, secondi})

   contro:

   • SCP / tar / etc. non mi piaceranno quei personaggi ':'.
   • Ci vuole un po 'per le persone "normali" per vedere WTF per cui "T" è, e qual è la cosa alla fine :).
   • Molti personaggi "-".

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
   

   professionisti:

   • Tiene conto di TZ.
   • Può essere facilmente letto da "tutti gli umani".
   • Può distinguere data / ora dal prefisso / suffisso.
   • Alcuni dei precedenti possono essere generati con $ (date --iso = {hours, seconds})

   contro:

   • Ha spazi nelle versioni temporali (il che significa che tutto il codice lo odierà).
   • SCP / tar / etc. non mi piaceranno quei personaggi ':'.

4. Adoro i trattini:

   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
   

   professionisti:

   • fondamentalmente un syslog / etc leggermente più bello. variante.

   contro:

   • Molti personaggi "-".
   • Presuppone TZ.

5. Adoro i trattini, con estensioni:

   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
   

   professionisti:

   • sostanzialmente una variante "I love hyphens" leggermente più bella.
   • Nessun personaggio strano.
   • Può distinguere data / ora dal prefisso / suffisso.

   contro:

   • Usando '.' qui è un po 'non tradizionale.
   • Presuppone TZ.

... quindi chiunque vuole dare una preferenza e un motivo, o più di uno (es. non preoccuparsi di TZ se è 95+% per rimanere locale in macchina, ma preoccuparsi molto se non lo è).

O, ovviamente, qualcosa che non è nell'elenco precedente.

1. Il formato ISO 8601 dovrebbe essere rispettato il più possibile, poiché è la cosa più vicina a uno standard.
2. La "T" non è abbastanza di un ostacolo per giustificare davvero sbarazzarsene.
3. I ':' sono potenzialmente assassini, quindi quelli dovrebbero essere evitati.
4. Per i motivi menzionati nelle risposte degli altri, è necessario utilizzare il tempo UTC (o "Z").
5. ISO 8601 include un formato che utilizza UTC (tempo 'Z'), che dovrebbe essere utilizzato.
6. ISO 8601 include un formato che non utilizza il carattere ':', che dovrebbe essere utilizzato.

Quindi ... prova i formati "migliori" di data e ora:

1. 20120317T1748Z

   • 100% secondo ISO 8601
   • solo caratteri alfanumerici (molto adatto per l'amministratore di sistema)
   • non il più veloce da leggere, ma sicuramente leggibile dal laico

2. 2012-03-17T1748Z

   • la parte della data è conforme a ISO 8601
   • la parte temporale è conforme a ISO 8601
   • la transizione tra data e ora è conforme alla norma ISO 8601
   • mescola il formato "esteso" ISO 8601 (data con trattini, ora con due punti) con il formato "base" ISO 8601 (data senza trattini, tempo senza due punti), che probabilmente non è del tutto corretto
   • aggiunge il carattere '-' (vs 1.)
   • un po 'più facile da leggere per i non addetti ai lavori (vs 1.)

3. 2012-03-17--1748Z

   • la parte della data è conforme a ISO 8601
   • la parte temporale è conforme a ISO 8601
   • la transizione tra data e ora non è conforme alla norma ISO 8601
   • mescola il formato "esteso" ISO 8601 con il formato "base" ISO 8601
   • un po 'più facile da leggere per i non addetti ai lavori (vs 1. e 2.)
   • nessun nuovo personaggio (vs 2.)

Sono parziale a 1. dato che è completamente IAW lo standard, ma gli altri sono vicini.

Nota :: Aggiungi secondi, se necessario, ovviamente. ... e sì, con o senza secondi (o anche minuti) è tutto IAW ISO 8601. :)

Non vorrei includere un fuso orario, utilizzare solo l'ora universale. Se ci può essere confusione, è possibile aggiungere un suffisso -UTC. Se si specifica un fuso orario, qualcuno potrebbe dipendere da esso. E ci sarebbero strani casi limite in cui i cambiamenti dell'ora legale o i cambiamenti dell'ora legale causano il caos su alcuni processi, o l'elaborazione è diversa su alcuni sistemi perché la loro configurazione dell'ora legale non è aggiornata. UTC è sempre lo stesso ovunque.

Penso che i trattini rendano più leggibile il nome del file, nel senso che rende più facile discernere il datetime dei dati del file. Se si desidera includere la precisione dei secondi inferiori, di solito è .nnnnn.

Personalmente non mi piace il T. L'uso dei due punti nel nome di un file può influire sull'interoperabilità con altri file system.

1. Anch'io non includerei i fusi orari. I tuoi script / strumenti che elaborano i log dovrebbero saperlo. Anche per quanto riguarda le modifiche dell'ora legale / solare, ti consiglio di mantenere il tuo server sempre fisso su UTC per tutto il tempo. Un'improvvisa differenza tra il fuso orario del server di base e un fuso orario (invariato) di un database in esecuzione su di esso può causare mal di testa ;-).

2. Per quanto riguarda la denominazione dei file di registro, lo so, a molti non piace, ma mi piace mantenerlo semplice:

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

professionisti:

• Comune denominatore
• molto facile da usare in ulteriori script

contro:

• non leggibile dall'uomo

Sulle macchine in cui i colleghi (per qualsiasi motivo) hanno bisogno di controllare manualmente i registri sono andato per questa variante, ruotando ogni giorno:

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

I migliori saluti