代表一天的最佳格式是什么？答案

【问题标题】：What's the best format to represent one day?代表一天的最佳格式是什么？
【发布时间】：2010-09-18 02:04:18
【问题描述】：

如何表示一天的开始和结束时间？

以 2008 年 10 月 23 日为例，是从 2008-10-23 12:00:00 AM 开始到 2008-10-23 11:59:59 PM 结束吗？

【问题讨论】：

您在寻找特定语言的示例吗？不同的语言会以不同的方式处理日期。
问题中未提及格式，但已被接受为答案，因此我将相应地编辑问题

标签： datetime representation

【解决方案1】：

我想引用一个网站，http://www.cl.cam.ac.uk/~mgk25/iso-time.html

一天中时间的国际标准符号是

hh:mm:ss

其中 hh 是自午夜 (00-24) 以来经过的完整小时数，mm 是自一小时开始 (00-59) 以来经过的完整分钟数，ss 是自分钟开始以来的完整秒数 (00-60)。如果小时值为 24，则分钟和秒值必须为零。

注意：在像协调世界时 (UTC) 这样的原子时间尺度中插入闰秒期间，有时可能需要 ss 的值 60。正如巴黎国际地球自转服务所宣布的那样，每隔几年将一个闰秒 23:59:60 插入 UTC 时间尺度，以防止 UTC 偏离不太恒定的天文时间尺度 UT1 超过 0.9 秒，这由地球的实际自转定义。实际上，您不太可能看到时钟显示 23:59:60。大多数同步时钟会在闰秒发生后的某个时间再次与 UTC 重新同步，或者它们会在闰秒时间附近暂时放慢速度，以避免超出范围的时间戳可能导致的任何中断。

一个例子时间是

23:59:59

表示午夜前一秒的时间。

与日期表示法一样，分隔冒号也可以省略，如

并且可以通过省略秒或同时省略秒和分钟来降低精度

23:59, 2359, or 23

还可以在小数点或逗号后添加秒的小数部分，例如午夜前 5.8 毫秒的时间可以写成

23:59:59.9942 or 235959.9942

由于每一天都以午夜开始和结束，因此可以使用 00:00 和 24:00 这两个符号来区分可以与一个日期相关联的两个午夜。这意味着以下两个符号指的是完全相同的时间点：

1995-02-04 24:00 = 1995-02-05 00:00

如果需要明确表示时间，00:00 通常是午夜的首选表示法，而不是 24:00。数字时钟显示 00:00 而不是 24:00。

ISO 8601 没有指定其符号是指定时间点还是时间段。这意味着，例如，ISO 8601 没有定义 09:00 是指一天中第九个小时的确切结束时间还是从 09:00 到 09:01 的时间段或其他任何时间。如果有任何问题，该标准的用户必须以某种方式就时间符号的确切解释达成一致。

如果日期和时间显示在同一行，则始终将日期写在时间前面。如果日期和时间值一起存储在单个数据字段中，则 ISO 8601 建议它们应该用拉丁文大写字母 T 分隔，如 19951231T235959。

致美国读者的感言：

几十年来，此处指定的 24 小时制时间符号已经成为全世界书面语言的事实标准。唯一的例外是少数说英语的国家/地区，仍然使用 1 到 12 小时之间的符号以及诸如“上午”之类的附加符号。和“下午”被广泛使用。通用的 24 小时国际标准符号现在甚至在英国也得到广泛使用（例如在机场、电影院、公共汽车/火车时刻表等）。大多数其他语言甚至没有像“a.m.”这样的缩写。和“下午” 12h 记法在欧洲大陆上肯定很少用于书写或显示时间。即使在美国，军方和计算机程序员也已经使用 24 小时表示法很长时间了。

旧的英文 12h 表示法有很多缺点，例如：

它比正常的 24 小时表示法要长。
人类用 12 小时表示法比较两次需要更多时间。
不清楚，如何表示 00:00、12:00 和 24:00。甚至百科全书和风格手册也包含相互矛盾的描述，一个常见的快速解决方法似乎是避免“12:00 a.m./p.m.”。一起写“中午”、“午夜”或“12:01 a.m./p.m.”相反，尽管“午夜”一词仍然无法区分 00:00 和 24:00（给定一天开始或结束时的午夜）。
它使人们常常认为第二天从“12:59 am”开始溢出。到“凌晨 1:00”，这不仅是人们试图在午夜过后不久对 VCR 的计时器进行编程时的常见问题。
不容易与字符串比较操作进行比较。
不清楚“12:00 a.m./p.m.”之间的时间是否是不知情的和“1:00 a.m./p.m.”从 00:00 或 12:00 开始，即英文 12h 表示法更难理解。

请认为 12 小时时间是使用罗马数字的黑暗时代的遗物，当时还没有发明数字零，而模拟时钟是唯一已知的显示时间的形式。请避免今天使用它，尤其是在技术应用中！即使在美国，广受推崇的芝加哥风格手册现在也建议在出版物中使用国际标准时间表示法。

【讨论】：

虽然我倾向于同意 24 小时制更好，但他确实问了一天的开始和结束时间，而不是美国读者应该使用什么格式。
发帖人的意思是，正如您所说，这个问题最好（甚至可能“仅”）以 24 小时格式回答，因为例如，“12:00am”是模棱两可的。
这个问题严格依附于日期和时间格式原则，没有它就没有任何意义。考虑到每种可能的格式，答案就很清楚了。使用 24 小时表示法：0:00 是一天开始，24:00 是一天结束，2008-10-23 24:00 = 2008-10-24 00:00

【解决方案2】：

当然，如果您只想表示 1 天，则根本不需要包含时间 - 尤其是因为这引发了关于一天何时开始或结束的如此程度的讨论。根据我的经验，日期处理通常足够复杂，不会引入任何额外的复杂性。

今天是 2008 年 10 月 20 日 - 不需要更多信息。

还是我错过了什么？

【讨论】：

这很可能是这个问题的最佳答案；至少，在问题澄清之前，它是。 +1

【解决方案3】：

十月。 23 日从 2008 年 10 月 23 日凌晨 12 点开始，到 2008 年 10 月 24 日凌晨 12 点结束——一天结束的时间与下一天开始的时间完全相同。最后一秒从晚上 11:59:59 开始，但在这一天结束之前，您还有整整一秒的时间。

【讨论】：

是的，如果你有毫秒精度，结束是 11:59:59.999
.NET 包含 100ns 的精度，这简直令人毛骨悚然。但这一点表明，马克思主义在大多数情况下是正确的。在进行日期范围比较时，使用指定结束边界而不是结束点的结束日期更简单。毕竟起点也是起点。

【解决方案4】：

你的符号很奇怪。我建议指定全天范围的标准方法是：

2008-10-23 00:00:00 并完成 2008-10-23 23:59:59

【讨论】：

这是错误的；即它不包括 23:59:59.000 和 23:59:59.999 之间的时间...？
@Simon，您提出了一个有效的观点，即该范围仅适用于比较不涉及几分之一秒的情况。但是，如果您想学究气，我没有放 2008-10-23 23:59:59.0，所以对于我引用的整个第二种情况，我实际上是正确的。
最好使用半开范围，例如 [begin, end)，其中 'begin' 的值包含在范围内，而 'end' 的值不包含在内；它定义了立即超出范围的值。那么一天的范围是：[2008-10-23 00:00:00, 2008-10-24 00:00:00)。没有混淆。
半开放范围处理闰秒。

【解决方案5】：

您在问题中提到的日期的定义是 >= 2008-10-23 00:00:00 和

【讨论】：

虽然您是对的，但由于必须计算下一个日期，因此您将其变得不必要地复杂。 >= 2008-10-23 00:00:00 和
不，它让它更简单，它处理闰秒，并且很容易看出两个间隔是否连续。
@janm，如果一个函数存在于一个特定的框架中，它可以为 day+1 的 00:00:00 提供日期时间结构，那么 Ben 的案例既简单又可靠。与测试相比，day+1 是一个复杂的函数

【解决方案6】：

如果你要使用数学区间表示法，你会写成

[2008-10-23 00:00:00 , 2008-10-24 00:00:00)

[表示包含，)表示最多但不包含。

通过这种方式，您可以让用户和您自己更轻松。

【讨论】：

【解决方案7】：

这取决于你所说的一天是什么意思。遗憾的是，日期处理总是比看起来复杂。

要将您的示例转换为 24 小时 ISO 日期格式，您会说：

2008-10-23 00:00:00 - 2008-10-23 23:59:59

但是，取决于您是否将范围解释为包含或排除可能会省略一天的最后一秒*。程序员通常更喜欢保持上限独占，所以你会选择：

2008-10-23 00:00:00 - 2008-10-24 00:00:00

或者，如果支持（或为了人类可读性），作为一种更好的陈述方式：

2008-10-23 00:00:00 - 2008-10-23 24:00:00

*：实际上可能不止一个。如果跨度表示 UTC 时区中的一天（或与之对齐的另一个时区，这很可能），则在一天结束时，有时会出现额外的“闰秒”，即 23:59:60，毫无意义尝试使 UTC 与恒星时保持一致。下一个闰秒计划在今年年底进行。但是，许多系统会忽略闰秒，因为它们既愚蠢又烦人。

如果您想独立于时区来表示“日历日”，您最好的选择是儒略日数。今天是 2454760。

【讨论】：