Jodatime start of day and end of day

Question

I want to create an interval between the beginning of the week, and the end of the current week.

I have the following code, borrowed from this answer:

private LocalDateTime calcNextSunday(LocalDateTime d) {
    if (d.getDayOfWeek() > DateTimeConstants.SUNDAY) {
        d = d.plusWeeks(1);
    }
    return d.withDayOfWeek(DateTimeConstants.SUNDAY);
}

private LocalDateTime calcPreviousMonday(LocalDateTime d) {
    if (d.getDayOfWeek() < DateTimeConstants.MONDAY) {
        d = d.minusWeeks(1);
    }
    return d.withDayOfWeek(DateTimeConstants.MONDAY);
}

But now I want the Monday LocalDateTime to be at 00:00:00, and the Sunday LocalDateTime at 23:59:59. How would I do this?

Solution 1

How about:

private LocalDateTime calcNextSunday(LocalDateTime d) {
    return d.withHourOfDay(23).withMinuteOfHour(59).withSecondOfMinute(59).withDayOfWeek(DateTimeConstants.SUNDAY);
}

private LocalDateTime calcPreviousMonday(final LocalDateTime d) {
    return d.withHourOfDay(0).withMinuteOfHour(0).withSecondOfMinute(0).withDayOfWeek(DateTimeConstants.MONDAY);
}

Solution 2

You can use the withTime method:

 d.withTime(0, 0, 0, 0);
 d.withTime(23, 59, 59, 999);

Same as Peter's answer, but shorter.

Solution 3

also a simple way is

d.millisOfDay().withMaximumValue();

Solution 4

With Kotlin you could write an extension function:

fun DateTime.withTimeAtEndOfDay() : DateTime = this.withTime(23,59,59,999)

This would allow you to write:

d.withDayOfWeek(DateTimeConstants.SUNDAY).withTimeAtEndOfDay()

View more solutions

Comments

[Mikkel R. Lund]

It is always a very bad idea to subtract a "small unit" from the end of time intervals. Time intervals have their start included and their end excluded. Checking if a (date)time is included in the interval you do: start <= time && time < end. Otherwise you end up with a small amount of values (actually in the interval) that suddenly get excluded. Think about the last second in your case. 23:59:59.5 is not in that interval. Using small units just makes the number of excluded values small, but doesn't remove the problem. Using the right comparison does.

[Hauke Ingmar Schmidt]

setXxx by convention has no return type in Java so it wouldn't allow chaining. This here reminds of the builder pattern (which originally would not work on an existing object).

[Louis Wasserman]

Indeed. This lets you string the calls together, rather than having them all on different lines, and gets you all the benefits of immutable objects.

[Peter Svensson]

I think the "pattern" is called "Fluent interface" martinfowler.com/bliki/FluentInterface.html - gives a lot of benefits in readability and clarity in my opinion.

[JodaStephen]

I wrote up the "with" verb in 2006 - blog.joda.org/2006/05/immutable-pojos-improving-on_6406.html and updated that in 2011 - blog.joda.org/2011/08/common-java-method-names.html . Immutable setters are very different from normal setters in terms of how you use them (you must use the return value).

[Apollon]

Beginning of the day can also be got with d.withTimeAtStartOfDay()

[Abdull]

withTimeAtStartOfDay() is not available for LocalDateTime, but it is available for DateTime

[informatik01]

+1. One note: LocalDateTime is immutable, so there are no set methods. Instead, this method returns a new instance with the value of millis of day changed. So you have to assign the result to some variable.

[informatik01]

Oh, I'm sorry. I have just noticed that I addressed my above note to the author of Joda-Time. Quite confusing. Sorry, sir.

[Feuermurmel]

Keep in mind that with this method, you're missing one millisecond of each day. I'd suggest using d.plusDays(1).withTime(0, 0, 0, 0) for the end of that day.

[yetanothercoder]

@Touko where is withTimeAtStartOfDay()? there is no such in LocalDateTime

[ryenus]

better to use plusDays(1).withTime(0,0,0,0) approach as @Feuermurmel pointed out, as it works with leap seconds, as for 2015-06-30T23:59:60

[le0diaz]

This should be the accepted answer, as compared with the other answers is the best in terms of performance (less objects created as DateTime is inmutable). The method withMaximunValue Documentation even says is the best way to accomplish what the question is asking

[le0diaz]

@TheRueger response is the best answer. This one is correct but has the the worst performance of current answers as it creates many objects in each withXXX method. d.millisOfDay().withMaximumValue(); is the one to accomplish the best posible way.

[deldev]

Pay attention the daylightsaving. Better to use d.millisOfDay().withMaximumValue();

[Yichuan Wang]

What is the difference with getMaximumValueOverall?

[Jules]

Wouldn't these potentially fail with an exception if the local timezone had a daylight savings time change that prevented the specified times existing?