タイムスタンプを含むファイル名の優先形式

「unix」はファイルに「/」と「\ 0」以外のすべてを含めることができることを知っていますが、システム管理者は、入力としてスペースを好むものがほとんどないため、はるかに小さい設定を持つ傾向があります... 「：」や「@」の特別な意味。

最近、ファイル名にタイムスタンプが使用されている別のケースを見ましたが、異なる形式で少し遊んで「より良い」ようにした後、私は考えたものではなく「ベストプラクティス」を見つけようと思いましたここで質問して、人々の考えを見てみましょう。

考えられる「一般的な」解決策（p = prefixおよびs = suffix）：

1. 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
   

   長所：

   • それは「共通」であるため、「十分」は「最良」よりも優れている可能性があります。
   • 変なキャラクターはいません。
   • 「日付/時刻blob」を他のすべてのものと簡単に区別できます。

   短所：

   • 日付のみのバージョンは読みやすくなく、時間を含めると目が出血し、秒も「笑」になります。
   • TZを想定しています。

2. 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
   

   長所：

   • 場所がない。
   • TZを考慮に入れます。
   • 人間が読むのは「悪くない」（日付のみが良い）。
   • $（date --iso = {hours、minutes、seconds}）で生成できます

   短所：

   • scp / tar / etc。これらの「：」文字は気に入らないでしょう。
   • 「普通の」人々が、「T」の目的であるWTFを見るには少し時間がかかります。最後にあるのは:)です。
   • 多くの「-」文字。

3. 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
   

   長所：

   • TZを考慮に入れます。
   • 「すべての人間」が簡単に読むことができます。
   • 日付/時刻とプレフィックス/サフィックスを区別できます。
   • 上記のいくつかは$（date --iso = {hours、seconds}）で生成できます

   短所：

   • 時間バージョンにスペースがあります（つまり、すべてのコードがそれを嫌います）。
   • scp / tar / etc。これらの「：」文字は気に入らないでしょう。

4. ハイフンが大好き：

   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
   

   長所：

   • 基本的にわずかに優れたsyslog / etc。バリアント。

   短所：

   • 多くの「-」文字。
   • TZを想定しています。

5. 拡張機能付きのハイフンが大好きです：

   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
   

   長所：

   • 基本的には、少しいい「ハイフンが大好き」のバリエーションです。
   • 変なキャラクターはいません。
   • 日付/時刻とプレフィックス/サフィックスを区別できます。

   短所：

   • 「。」を使用する ここはやや非伝統的です。
   • TZを想定しています。

...だから誰もが好みと理由、または複数を与えたい（例えば、マシンのローカルにとどまるのが95％以上ならTZを気にかけないが、そうでなければたくさん気にする）。

または、明らかに、上記のリストにないもの。

1. ISO 8601形式は、標準に最も近いものであるため、できるだけ厳守する必要があります。
2. 「T」はつまずきのブロックとしては十分ではなく、本当にそれを取り除くことを保証します。
3. 「：」は潜在的にキラーであるため、それらは避ける必要があります。
4. 他の回答で述べられている理由により、UTC（または「Z」時間）を使用する必要があります。
5. ISO 8601には、UTC（ 'Z'時間）を使用する形式が含まれています。これを使用する必要があります。
6. ISO 8601には、使用すべき「：」文字を使用しない形式が含まれています。

だから...サンプルの「最高の」日時形式：

1. 20120317T1748Z

   • ISO 8601に準拠した100％
   • 英数字のみ（システム管理者にとって非常に使いやすい）
   • 読むのが最も速いわけではありませんが、素人が確実に読むことができます

2. 2012-03-17T1748Z

   • 日付部分はISO 8601に準拠しています
   • 時間部分はISO 8601に準拠しています
   • 日付と時刻間の移行はISO 8601に準拠しています
   • ISO 8601「拡張」形式（ハイフンを含む日付、コロンを含む時間）とISO 8601「基本」形式（ハイフンを含まない日付、コロンを含まない時間）を混合します。
   • 「-」文字を追加します（vs 1.）
   • 素人にとって読みやすい（vs 1.）

3. 2012-03-17--1748Z

   • 日付部分はISO 8601に準拠しています
   • 時間部分はISO 8601に準拠しています
   • 日付と時刻間の移行がISO 8601に準拠していない
   • ISO 8601「拡張」フォーマットとISO 8601「基本」フォーマットを混合
   • 素人が読むのが少し楽（vs 1.および2.）
   • 新しいキャラクターなし（vs 2.）

それは完全に標準のIAWであるが、他は近いので、私は1に部分的です。

注::もちろん、必要に応じて秒を追加してください。...そして、はい、秒（または数分）の有無にかかわらず、すべてIAW ISO 8601です。:)

タイムゾーンは含めず、世界時のみを使用します。混乱が生じる可能性がある場合は、-UTCサフィックスを追加できます。タイムゾーンを指定すると、誰かがそれに依存する場合があります。また、DSTの変更やDSTシフトが一部の処理で大混乱を招いたり、DST構成が最新ではないために一部のシステムで処理が異なるといった奇妙なケースがあります。UTCはどこでも常に同じです。

ハイフンを使用すると、ファイルデータの日時を識別しやすくなるという意味で、ファイル名が読みやすくなると思います。秒未満の精度を含める場合、通常は.nnnnnです。

私は個人的にTが好きではありません。ファイル名にコロンを使用すると、他のファイルシステムとの相互運用性に影響する場合があります。

1. 私もタイムゾーンを含めません。ログを処理するスクリプト/ツールはそれについて知っている必要があります。また、夏時間/冬時間の変更に関しては、常にサーバーを常にUTCに固定することをお勧めします。ベースサーバーのタイムゾーンと、その上で実行されているデータベースの（変更されていない）タイムゾーンの突然の違いは、頭痛の種になります;-)。

2. ログファイルの命名について-私は知っていますが、多くの人はそれを好きではありませんが、私はそれをシンプルに保つのが好きです：

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

長所：

• 共通分母
• さらなるスクリプトで非常に使いやすい

短所：

• 人間が読めない

同僚が（何らかの理由で）ログを手動で確認する必要があるマシンでは、このバージョンを毎日使用しました。

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

宜しくお願いします