问题 Joda Time LocalTime 24:00结束

23:59:59之后，第二天00:00:00到来。所以也许用一个 LocalTime 的 0, 0 在下一个日历日？

虽然因为你的开始和结束时间是包容性的，但是23:59:59真的是你想要的。这包括第23个小时的第59分钟的第59秒，并在00:00:00准确结束范围。

没有24:00（使用时） LocalTime）。

这不是设计缺陷。 LocalDate 不处理 (24,0) 因为没有24:00这样的事情。

此外，当您想要表示介于晚上9点到凌晨3点之间的间隔时会发生什么？

这有什么问题：

new LocalInterval(new LocalTime(23, 0), new LocalTime(0, 0));

你只需要处理结束时间可能在开始时间“之前”的可能性，并在必要时添加一天，并且只希望没有人想要表示超过24小时的间隔。

或者，将间隔表示为a的组合 LocalDate 和a Duration 要么 Period。这消除了“超过24小时”的问题。

您的问题可以被定义为在包围的域上定义间隔。您的最低时间是00:00，最高时间是24:00（不包括在内）。

假设您的间隔定义为（下限，上限）。如果您需要低于<upper，则可以表示（21：00,24：00），但仍然无法表示（21：00,02：00），这是一个跨越最小/最大边界的间隔。

我不知道你的日程安排应用程序是否会涉及环绕间隔，但是如果你打算在没有涉及日期的情况下去（21：00,24：00），我不会看到什么会阻止你要求（21 ：00,02：00）没有涉及天（因此导致环绕维度）。

如果您的设计适合于环绕式实现，则间隔运算符非常简单。

例如（在伪代码中）：

is x in (lower, upper)? :=
if (lower <= upper) return (lower <= x && x <= upper)
else return (lower <= x || x <= upper)

在这种情况下，我发现在Joda-Time周围编写一个实现运算符的包装器非常简单，并且减少了思想/数学和API之间的阻抗。即使它只是将24:00包含在00:00。

我同意24:00的排除在一开始就让我烦恼，如果有人提供解决方案，那将会很好。幸运的是，鉴于我使用时间间隔由环绕语义控制，我总是最终得到一个包装器，顺便解决了24:00的排除问题。

24:00的时间是一个困难的时间。虽然我们人类可以理解是什么意思，但编写一个API代表那个而不会对其他一切产生负面影响，但在我看来几乎是不可能的。

无效的值24在Joda-Time中被深度编码 - 试图删除它会在很多地方产生负面影响。我不建议尝试这样做。

对于您的问题，本地间隔应由两者组成 (LocalTime, LocalTime, Days) 要么 (LocalTime, Period)。后者稍微灵活一点。这需要正确支持从23:00到03:00的间隔。

我发现 JodaStephen的建议 (LocalTime, LocalTime, Days) 可以接受的。

考虑到2011年3月13日，您可以在周日00：00-12：00之间使用 (00:00, 12:00, 0) 实际上因为夏令时长达11个小时。

从15：00-24：00可用，然后您可以编码为 (15:00, 00:00, 1) 这将扩大到2011-03-13T15：00 - 2011-03-14T00：00，最终将在2011-03-13T24：00结束。这意味着您将在下一个日历日使用00:00的LocalTime aroth 建议。

当然最好直接使用24:00 LocalTime和ISO 8601一致，但这似乎不可能不改变JodaTime内部的很多，所以这种方法似乎是较小的邪恶。

最后但并非最不重要的是，你甚至可以用类似的东西延长一天的障碍 (16:00, 05:00, 1)...

这是我们对TimeInterval的实现，使用null作为结束日期的结束日期。它支持overlapps（）和contains（）方法，也基于joda-time。它支持跨越多天的间隔。

/**
 * Description: Immutable time interval<br>
 * The start instant is inclusive but the end instant is exclusive.
 * The end is always greater than or equal to the start.
 * The interval is also restricted to just one chronology and time zone.
 * Start can be null (infinite).
 * End can be null and will stay null to let the interval last until end-of-day.
 * It supports intervals spanning multiple days.
 */
public class TimeInterval {

    public static final ReadableInstant INSTANT = null; // null means today
//    public static final ReadableInstant INSTANT = new Instant(0); // this means 1st jan 1970

    private final DateTime start;
    private final DateTime end;

    public TimeInterval() {
        this((LocalTime) null, null);
    }

    /**
     * @param from - null or a time  (null = left unbounded == LocalTime.MIDNIGHT)
     * @param to   - null or a time  (null = right unbounded)
     * @throws IllegalArgumentException if invalid (to is before from)
     */
    public TimeInterval(LocalTime from, LocalTime to) throws IllegalArgumentException {
        this(from == null ? null : from.toDateTime(INSTANT),
                to == null ? null : to.toDateTime(INSTANT));
    }

    /**
     * create interval spanning multiple days possibly.
     *
     * @param start - start distinct time
     * @param end   - end distinct time
     * @throws IllegalArgumentException - if start > end. start must be <= end
     */
    public TimeInterval(DateTime start, DateTime end) throws IllegalArgumentException {
        this.start = start;
        this.end = end;
        if (start != null && end != null && start.isAfter(end))
            throw new IllegalArgumentException("start must be less or equal to end");
    }

    public DateTime getStart() {
        return start;
    }

    public DateTime getEnd() {
        return end;
    }

    public boolean isEndUndefined() {
        return end == null;
    }

    public boolean isStartUndefined() {
        return start == null;
    }

    public boolean isUndefined() {
        return isEndUndefined() && isStartUndefined();
    }

    public boolean overlaps(TimeInterval other) {
        return (start == null || (other.end == null || start.isBefore(other.end))) &&
                (end == null || (other.start == null || other.start.isBefore(end)));
    }

    public boolean contains(TimeInterval other) {
        return ((start != null && other.start != null && !start.isAfter(other.start)) || (start == null)) &&
                ((end != null && other.end != null && !other.end.isAfter(end)) || (end == null));
    }

    public boolean contains(LocalTime other) {
        return contains(other == null ? null : other.toDateTime(INSTANT));
    }

    public boolean containsEnd(DateTime other) {
        if (other == null) {
            return end == null;
        } else {
            return (start == null || !other.isBefore(start)) &&
                    (end == null || !other.isAfter(end));
        }
    }

    public boolean contains(DateTime other) {
        if (other == null) {
            return start == null;
        } else {
            return (start == null || !other.isBefore(start)) &&
                    (end == null || other.isBefore(end));
        }
    }

    @Override
    public String toString() {
        final StringBuilder sb = new StringBuilder();
        sb.append("TimeInterval");
        sb.append("{start=").append(start);
        sb.append(", end=").append(end);
        sb.append('}');
        return sb.toString();
    }
}

为了完整起见，此测试失败：

@Test()
public void testJoda() throws DGConstraintViolatedException {
    DateTimeFormatter simpleTimeFormatter = DateTimeFormat.forPattern("HHmm");
    LocalTime t1 = LocalTime.parse("0000", simpleTimeFormatter);
    LocalTime t2 = LocalTime.MIDNIGHT;
    Assert.assertTrue(t1.isBefore(t2));
}  

这意味着MIDNIGHT常量对问题不是很有用，正如有人建议的那样。

这个问题很古老，但这些答案中的很多都集中在Joda Time上，而且只能部分解决真正的潜在问题：

OP代码中的模型与其建模的实际情况不符。

不幸的是，由于你似乎关心天之间的边界条件，你的“优雅模型”并不适合你正在建模的问题。您已使用一对时间值来表示间隔。尝试将模型简化为一对简化 低于现实世界问题的复杂性。实际上，日间界限确实存在，并且一次失去了那种类型的信息。与往常一样，过度简化会导致后续复杂性，以恢复或补偿丢失的信息。真正的复杂性只能从代码的一部分推到另一部分。

现实的复杂性只能通过“不支持的用例”的魔力来消除。

您的模型只有在问题空间才有意义，在这个问题空间中，人们不关心开始和结束时间之间可能存在多少天。这个问题空间与大多数现实世界的问题都不相符。因此，Joda Time不能很好地支持它并不奇怪。小时位置（0-24）使用25个值是a 代码味道 并且通常指出设计中的弱点。一天只有24小时，所以不需要25个值！

请注意，因为您没有捕获任何一端的日期 LocalInterval，您的班级也没有捕获足够的信息来说明夏令时。 [00:30:00 TO 04:00:00) 通常为3.5小时，但也可能是2.5小时或4.5小时。

您应该使用开始日期/时间和持续时间，或者开始日期/时间和结束日期/时间（包括开始，独占结束） 是一个很好的默认选择）。如果您打算显示结束时间，则使用持续时间变得棘手，因为夏令时，闰年和闰秒等事情。另一方面，如果您希望显示持续时间，则使用结束日期变得非常棘手。存储两者当然是危险的，因为它违反了 干燥原则。如果我正在编写这样的类，我将存储结束日期/时间并封装逻辑以通过对象上的方法获得持续时间。这样，类类的客户端并不都会提供自己的代码来计算持续时间。

我编写了一个例子，但是有一个更好的选择。使用标准 间隔 Joda时间的等级，已经接受了一个开始时刻，持续时间或结束时刻。它也会愉快地为您计算持续时间或结束时间。可悲的是，JSR-310没有间隔或类似的类别。 （虽然可以使用 ThreeTenExtra 弥补那个）

Joda Time和Sun / Oracle相对光明的人（JSR-310）都非常仔细地考虑过这些问题。你可能比他们聪明。这是可能的。然而，即使你是一个更明亮的灯泡，你的1小时可能无法完成他们多年来所做的事情。除非你处于一个深奥的边缘情况中，否则花费时间和金钱来花费精力再次猜测它们。 （当然在OP JSR-310时尚未完成......）

希望上述内容能够帮助那些在设计或修复类似问题时找到这个问题的人。