就国际化而言，"just a date without time" 真的是一个有效的概念吗？

Question

我总是在概念上遇到日期值被表示为没有时间的对象的问题（例如 SQL 在 DATETIME 旁边有类型 DATE）。同样的想法经常会在总是将日期与时间一起存储的语言中产生问题（例如 C# 的 DateTime）。突然弹出时区错误，开发人员坚持可以忽略所有时区喧嚣，因为他们的 DateTime 实际上是 "just a date"。但这到底是什么意思？

在我看来，这样的 "plain date" 只能用两种方式解释：

从时间点的角度（即"instants"）可以推断“2019-09-17”是一天的开始（结束），即“2019-09-17 00:00:00”（“2019-09-17 23:59:59”）。因此，时区信息是相关的，我们不是在谈论 "just a date".
另一种选择是日期应该表示一整天，所以我们实际上是在谈论来自“2019-09-17 00:00:00 的 timespan " 到 "2019-09-17 23:59:59" 时区信息也不能忽略。

我认为 "plain dates" 的所有用例都属于这两个类别中的任何一个，并且如果软件仅运行并与系统通信，则 time/timezone 只能被忽略配置了完全相同的时区。

有人可以提供反例或第三种解释吗？

Answer 1

"holiday"是一个没有时间甚至没有时区的日期的例子。

大多数假期本质上都是宗教性的，我不想开始一个宗教性的 war，或者被细枝末节打扰。因此，作为示例假期，我将选择地球日：民历每年的 4 月 22 日。

如果您编写处理假期的 software，则表示 software 不一定处理整个地球上的某个时间点（尽管它可以另外处理跟踪假期）。相反，它带有将每年的 4 月 22 日映射到地球日的概念。有些人会在其他人之前或之后几个小时庆祝地球日是无关紧要的。

如果客户想知道他的地球日 starts/ends 的确切时间，那么他可以使用他的特定时区将 "the date" 翻译成特定的时刻。翻译的需要不会降低日期的价值（比如 2020-04-22）。

C++20 将有几种类型来表示 "timezone-less date" 例如 2020-04-22 使用不同的数据结构：

local_days         // day 18374                   == April/22/2020
year_month_day     // year 2020, month 4, day 22  == April/22/2020
year_month_weekday // year 2020, month 4, 4th Wed == April/22/2020

就国际化而言，"just a date without time" 真的是一个有效的概念吗？

Is "just a date without time" really a valid concept in the light of internationalization?

timezone

datetime

internationalization

jodatime

nodatime