0

应用：Java + ExtJS

有很多不同的实体具有 java.util.Date 类型的属性：startDate 和 iesendDate（endDate 可以为 NULL）。可以选择带或不带时间部分的两个日期（例如，始终保留时间部分，如果未选择则为事件）。例如，像这样：

2010-07-01 00:00:00

当用户没有时间选择 endDate 时，可能会出现问题。例如，期间从 2010 年 7 月 1 日开始，到 1010 年 7 月 4 日结束。现在在数据库中，它的存储方式如下：

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 小时 - 而是（24 小时 - 0.(9) 毫秒），这可能是潜在的问题。时间部分看起来也很丑陋。
  2. 要修改 ExtJs 组件，它将添加 1 天到用户在持久性阶段选择的日期，并在该日期显示给用户时再次减去 1 天（用户明确设置时间部分的情况除外）。我不喜欢这里有时间部分的日期和没有它的日期被区别对待。
  3. 例如，仅将开始日期保存为 Date 对象，然后以秒为单位保存期间的长度。这种方法看起来相当不错——但必须重新设计整个应用程序，并且可能不太容易在结束日期上使用不同的比较。
  4. 只需使用当前的 - 保存不包含时间的非包含结束日期，并且在日期比较期间要非常小心

有人可以解释解决此类问题的最广泛使用的做法吗？

4

3 回答 3

2

我最近从您的第一种方法更改为第二种方法。

方法 1：“2010-07-04 23:59:99”应该是“2010-07-04 23:59:59”，但无论如何它确实很丑陋，从技术上讲，它会失去一秒钟。我确实遇到的另一个问题是，我想以与停止另一条记录相同的数据/时间开始一条记录。因此，有可能找到记录的继任者。而对于方法 1，这是无法做到的，因为时间将区分 1 秒。

方法2：结束日期将是“2010-07-05”，查询条件将< endDate代替<= endDate方法1。这里的结束日期意思是“直到”或“直到”或“最多”，而不像方法中的那样1“直至并包括”。出于这个原因，在新项目中我确实使用了tillDate，或者实际上我使用了serviceStart / serviceTill之类的东西。

缺点确实是在向用户显示时将其格式化为 -1 天。但对我来说，这是有道理的。

于 2021-11-17T21:13:24.807 回答
0

将结束日期添加为用户选择值的 +1 天。

于 2012-11-15T15:02:06.660 回答
0

单独的模型和演示文稿

将存储在数据库中的结束时间与向用户显示的结束时间完全分开。

在数据库中存储结束日期和时间：由于您总是存储日期和时间，因此您应该清楚地存储真实的日期和时间。如果期间在 7 月 4 日至 5 日午夜结束，则存储此时间，因此2010-07-05 00:00:00.

呈现给用户：我不能说您的用户希望如何看到结束时间，您应该询问用户自己。也许他们会告诉你：

  • 照原样。2010-07-05 00:00:00.
  • 作为期间最后一天的 24 小时， 2010-07-04 24:00:00.
  • 仅作为日期的最后一天2010-07-04（我认为这不太可能，尤其是开始时间不是午夜）。
  • 或者是其他东西。

所以，是的，你很可能必须在午夜结束时特别为演示文稿处理。它不像您需要在业务逻辑中特别对待它那样糟糕。

于 2021-11-18T18:50:00.357 回答