适用范围：Java +外部JS
有很多不同的实体具有java.util.Date类型的属性：startDate和iesendDate（endDate可以为NULL）。这两个日期都可以选择，也可以不选择时间部分（例如，始终保留时间部分，如果未选择，则为事件）。例如，如下所示：
2010-07-01 00:00:00当用户选择endDate而不选择时间时，可能会出现问题。例如，期间开始于2010-07-01，结束于1010-07-04。目前，在数据库中，它的存储方式如下：
startDate="2010-07-01 00:00:00"
endDate="2010-07-04 00:00:00".因此，该期间似乎在2010-07-04的第一秒结束。但正如用户所假设的，该endDate已隐含包括在内，例如，该期间在2010-07-04的最后一秒结束。系统中有许多不同期间的日期比较。
如何在这种情况下正确地存储结束日期？
我想过可能的解决办法，但所有的办法似乎都有点不对头：
1.要像这样存储结束日期的时间部分：“2010-07-04 23：59：99”。但似乎结束日期天不是24 h-而是（24 h- 0.（9）毫秒），这可能是潜在的问题。而且时间部分看起来相当丑陋。
1.修改ExtJs组件，使其在持久化阶段将用户选择的日期加上1天，并在向用户显示该日期时再次减去1天（用户明确设置时间部分的情况除外）。我不喜欢这里对带有时间部分和不带有时间部分的日期进行不同处理。
1.例如，只将开始日期保存为Date对象，然后保存以秒为单位的时段长度。这种方法看起来相当不错--但必须重新编写整个应用程序，而且可能不太容易对结束日期使用不同的比较。
1.仅使用当前日期-保存不带时间的非封闭结束日期，并且在日期比较期间要非常小心
有人能解释一下解决这类问题最常用的做法吗？
3条答案
按热度按时间cczfrluj1#
我最近从你的第一种方法变成了第二种方法。
方法1：“2010-07-04 23：59：99”应该是“2010-07-04 23：59：59”，但无论如何，它确实很难看，从技术上讲，它丢失了一秒。我遇到的另一个问题是，我想用与另一个记录停止时相同的日期/时间开始一个记录。因此，有可能找到记录的后续记录。而方法1无法做到这一点，因为时间将相差1秒。
方法2：结束日期将是“2010-07-05”，查询条件将是
< endDate，而不是方法1的<= endDate。这里的结束日期是指“直到”或"直到"或"直到“，而不是像方法1中的”直到并包括“。因此，在新项目中，我确实使用tillDate，或者实际上我使用类似serviceStart / serviceTill的东西。缺点是在显示给用户时，格式设置为-1天。但对我来说，这是有意义的。
kzmpq1sx2#
将结束日期添加为用户所选值的+1天。
rur96b6h3#
单独的模型和演示
务必将数据库中存储的结束时间与向用户显示的结束时间完全分开。
**在数据库中存储结束日期和时间：**由于您总是同时存储日期和时间，因此应清楚地存储真实日期和时间。如果时段在7月4日和5日之间的午夜结束，则存储此时间，因此
2010-07-05 00:00:00。**呈现给使用者：**使用者希望如何看到结束时间，我不知道，您应该问使用者自己。也许他们会告诉您：
2010-07-05 00:00:00.2010-07-04 24:00:00。2010-07-04（我认为这不太可能，尤其是开始的时间不是午夜）。所以，是的，你很可能不得不 * 为了演示 * 而 * 特别对待午夜结束，这远不如你 * 在你的业务逻辑中 * 需要特别对待它那么糟糕。