使用什么系统默认日期格式？
我正在为我们的应用程序设定标准。
我一直想知道，我应该选择使用什么默认日期格式？
应该是：
- 国际化&时区感知，该格式应该能够表示用户本地时间
- 可以通过 SimpleDataFormat（或类似的，仅限 jdk 类）有效解析
- 编程语言不可知（可以用 java、python 进行解析，上帝禁止 C++ :) 和 co.）
- 最好基于 ISO或其他公认的标准
- 易于通过 HTTP 进行通信（如果出现这种需要，JSON 或 YAML 或类似的东西）
- 可以将时间表示为秒分辨率（越精确越好，如果可能的话，微秒）。
- 人类可读是一个优点，但不是必需的
- 紧凑是一个优点，但不是必需的
谢谢，
格言。
I'm setting the standards for our application.
I've been wondering, what default date format should I choose to use ?
It should be:
- Internationalization & timezone aware, the format should be able to represent user local time
- Can be efficiently parsed by SimpleDataFormat (or alike, jdk classes only)
- Programming Language agnostic (can parse in java, python, god forbid C++ :) and co.)
- Preferably ISO based or other accepted standard
- Easy to communicate over HTTP (Should such need arises, JSON or YAML or something in this nature)
- Can represent time down to seconds resolution (the more precise the better, micro seconds if possible).
- Human readable is a plus but not required
- Compact is a plus but not required
Thank you,
Maxim.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
yyyy-MM-ddThh:mmZ （参见 ISO 8601）您可以添加秒等
您可以阅读很容易，这对于 SimpleDateFormat 来说不是问题。
yyyy-MM-ddThh:mmZ (See ISO 8601) You can add seconds, etc
You can read it easily, it will not be a problem for SimpleDateFormat.
最规范和标准的形式可能是 "Unix Time"：自协调午夜以来经过的秒数1970 年 1 月 1 日的世界时间 (UTC)。
如果将其设置为默认时间格式，您可以轻松解析它、将其存储在内存中、将其写入磁盘、通过 HTTP 轻松进行通信等等。它也绝对是一个公认的标准，从某种意义上说，它是“时区感知”的，因为无论时区如何，它都是明确定义的。
（这是我总是存储所有时间戳的格式；在数据库中、内存中、磁盘上……）
The most canonical and standard form is probably "Unix Time": The number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1, 1970.
If you set that as the default time-format you can easily parse it, store it in memory, write it to disk, easily communicate it over HTTP and so on. It is also definitely an accepted standard, and in a sense it is "time-zone aware", since it is well-defined regardless of time-zones.
(This is the format in which I always store all my time stamps; in databases, in memory, on disk, ...)
“正确的”默认格式实际上取决于您用它做什么。解析、存储和显示的格式都可以不同。
为了存储日期，您（几乎）总是想要使用 UTC，正如 aioobe 所说，即使您想以用户本地时间显示它。我说“（几乎）”，但我真的想不出有什么情况我会不想要使用 UTC 来保存日期。您可能还想存储日期来源的 TZ 信息，以便您可以以当地时间报告它，但更常见的是您希望显示当前的本地时间查看日期。这意味着无论原始当地时间是什么，都有一种方法可以确定当前用户的当地时间。
为了显示它，“默认格式”通常应由查看者的区域设置确定。 08/09/10 在美国通常表示 2010 年 8 月 9 日（“中端< /a>")，但在世界其他大部分地区通常表示 2010 年 9 月 8 日 ("小端字节序"）。 ISO-8601 格式“2010-09-10”安全且明确，但通常不是人们期望看到的。您还可以在互联网上查看 RFC-3339 来了解日期和时间RFC-2822 用于消息格式（传输日期）
对于解析日期，您需要解析它并将其转换为 UTC，但您应该对您接受的内容相当灵活。同样，最终用户的区域设置和时区（如果可以发现）可以帮助您确定接受什么格式的字符串作为输入。这是假设用户输入的字符串。如果您要生成日期/时间戳，您可以控制表单并且解析将没有问题。
我还第二个 BalusC 链接，我以前没有见过并且有现在已收藏。
The "right" default format really depends on what you're doing with it. The formats for parsing, storing, and displaying can all be different.
For storing the date you're (almost) always going to want to use UTC as aioobe says, even when you want to display it in user local time. I say "(almost)" but I really can't think of a case where I would not want UTC for a saved date. You may want to store the TZ information for where the date originated also, so you can report it in that local time, but more often you want to display the local time for the whoever is currently looking at the date. That means having a way to determine the current user's local time regardless of what the original local time was.
For displaying it, the "default format" should usually be determined by the viewers locale. 08/09/10 usually means 2010-Aug-9 in the U.S. ("Middle endian") but normally means 2010-Sep-8 in most of the rest of the world ("Little endian"). The ISO-8601 format "2010-09-10" is safe and unambiguous but often not what people expect to see. You can also look over RFC-3339 for Date and Time on the internet and RFC-2822 for message format (transmitting the date)
For parsing a date, you'll want to parse it and convert it to UTC, but you should be fairly flexible on what you accept. Again, the end users Locale and timezone, if discoverable, can help you determine what format(s) of string to accept as input. This is assuming user-typed strings. If you're generating a date/time stamp you can control the form and parsing will be no problem.
I also second BalusC link which I hadn't seen before and have now favorited.