包含时间戳的文件名的首选格式

Question

众所周知，“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。
   • 人类阅读“还不错”（仅日期是 v. 好）。
   • 可以通过 $(date --iso={hours,minutes,seconds}) 生成

   缺点：

   • scp/tar/等。不会喜欢那些 ':' 字符。
   • “正常”的人需要一点时间才能看到“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/等。不会喜欢那些 ':' 字符。

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
   

   优点：

   • 基本上是一个稍微好一点的系统日志/等。变体。

   缺点：

   • 很多'-'字符。
   • 假设 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，但如果不是，则非常关心）。

或者，显然，上面列表中没有的东西。

Answer 1

1. 应尽可能遵守 ISO 8601 格式，因为它是最接近标准的格式。
2. “T”不足以成为真正保证摆脱它的绊脚石。
3. ':' 是潜在的杀手，因此应该避免使用它们。
4. 由于其他人的答案中提到的原因，应使用 UTC（或“Z”时间）。
5. ISO 8601 包含使用 UTC（'Z' 时间）的格式，应使用该格式。
6. ISO 8601 包含一种不使用应该使用的“:”字符的格式。

所以...示例“最佳”日期时间格式：

1. 20120317T1748Z

   • 100% 符合 ISO 8601
   • 仅限字母数字字符（非常系统管理员友好）
   • 不是最快的阅读，但肯定是外行人可读的

2. 2012-03-17T1748Z

   • 日期部分符合 ISO 8601
   • 时间部分符合 ISO 8601
   • 日期和时间之间的转换符合 ISO 8601
   • 将 ISO 8601“扩展”格式（带连字符的日期，带冒号的时间）与 ISO 8601“基本”格式（不带连字符的日期，不带冒号的时间）混合，这可能不太正确
   • 添加“-”字符（vs 1。）
   • 外行人更容易阅读（与 1 相比）

3. 2012-03-17--1748Z

   • 日期部分符合 ISO 8601
   • 时间部分符合 ISO 8601
   • 日期和时间之间的转换不符合 ISO 8601
   • 将 ISO 8601“扩展”格式与 ISO 8601“基本”格式混合
   • 外行人更容易阅读（与 1. 和 2. 相比）
   • 没有新角色（vs 2）

我偏向于 1. 因为它完全符合 IAW 标准，但其他标准很接近。

注意：当然，根据需要添加秒数。...是的，有或没有秒（甚至分钟）都是 IAW ISO 8601。:)