Ich möchte ein Intervall zwischen dem Beginn der Woche und dem Ende der aktuellen Woche erstellen.
Ich habe den folgenden Code, der dieser Antwort entlehnt ist:
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);
}
Aber jetzt will ich den Montag LocalDateTime um 00:00:00 sein, und am Sonntag LocalDateTime um 23:59:59. Wie würde ich das tun?
Es ist immer ein sehr schlechte Idee, eine “kleine Einheit” vom Ende der Zeitintervalle abzuziehen. Zeitintervalle haben ihren Beginn eingeschlossen und ihr Ende ausgeschlossen. Überprüfen Sie, ob eine (Datums-)Zeit in dem Intervall enthalten ist, das Sie tun: Start <= Zeit && Zeit < Ende. Andernfalls erhalten Sie am Ende eine kleine Anzahl von Werten (eigentlich im Intervall), die plötzlich ausgeschlossen werden. Denken Sie in Ihrem Fall an die letzte Sekunde. 23:59:59,5 liegt nicht in diesem Intervall. Die Verwendung kleiner Einheiten verringert nur die Anzahl der ausgeschlossenen Werte, beseitigt das Problem jedoch nicht. Mit dem richtigen Vergleich tut es.
Beginn des Tages kann auch mit bekommen werden d.withTimeAtStartOfDay()
– Tuko
19. Februar 2013 um 13:26 Uhr
withTimeAtStartOfDay() steht nicht zur Verfügung LocalDateTimeaber es ist verfügbar für DateTime
– Abdul
31. Oktober 2013 um 12:18 Uhr
Denken Sie daran, dass Ihnen bei dieser Methode jeden Tag eine Millisekunde fehlt. Ich würde vorschlagen, zu verwenden d.plusDays(1).withTime(0, 0, 0, 0) für das Ende dieses Tages.
– Feuermurmel
26. August 2014 um 9:01 Uhr
besser zu gebrauchen plusDays(1).withTime(0,0,0,0) Ansatz, wie @Feuermurmel betonte, da er mit Schaltsekunden funktioniert, wie für 2015-06-30T23:59:60
– Ryenus
13. Juli 2015 um 10:33 Uhr
Achten Sie auf die Sommerzeit. Besser zu verwenden d.millisOfDay().withMaximumValue();
– dellasavia
25. Mai 2016 um 13:24 Uhr
auch eine einfache Möglichkeit ist
d.millisOfDay().withMaximumValue();
Dies sollte die akzeptierte Antwort sein, da die Leistung im Vergleich zu den anderen Antworten am besten ist (weniger Objekte werden erstellt, da DateTime unveränderlich ist). Die Methode withMaximunValue Documentation sagt sogar, dass sie der beste Weg ist, um das zu erreichen, was die Frage stellt
setXxx per Konvention hat keinen Rückgabetyp in Java, so dass es keine Verkettung zulassen würde. Dies hier erinnert an das Builder-Muster (das ursprünglich nicht auf einem bestehenden Objekt funktionieren würde).
– Hauke-Ingmar Schmidt
5. Februar 2012 um 22:53 Uhr
In der Tat. Auf diese Weise können Sie die Aufrufe aneinanderreihen, anstatt sie alle auf verschiedenen Leitungen zu haben, und Sie erhalten alle Vorteile von unveränderlichen Objekten.
– Louis Wassermann
6. Februar 2012 um 2:28 Uhr
Ich denke, das “Muster” heißt “Fluent Interface” martinfowler.com/bliki/FluentInterface.html – bietet meiner Meinung nach viele Vorteile in Bezug auf Lesbarkeit und Klarheit.
@TheRueger Antwort ist die beste Antwort. Diese ist richtig, hat aber die schlechteste Leistung der aktuellen Antworten, da sie viele Objekte in jeder withXXX-Methode erstellt. d.millisOfDay().withMaximumValue(); ist derjenige, der den bestmöglichen Weg erreicht.
– le0diaz
26. Januar 2016 um 22:34 Uhr
GreeneCreations
Für diejenigen, die hierher kommen und nach der Antwort auf „js-joda“ suchen, haben Sie zwei Möglichkeiten, je nachdem, was Sie erreichen möchten
Option 1: Sie möchten, dass der Tagesbeginn in derselben Zeitzone beginnt
Da Sie sich dafür entschieden haben, Ihre Zeiten basierend auf einem Zeitpunkt in Bezug auf eine Zeitzone zu berechnen, sollten Sie ZonedDateTime verwenden:
import { ZonedDateTime, LocalDate, ZoneId, DateTimeFormatter} from "js-joda";
import 'js-joda-timezone';
const nowInNewYorkCity = ZonedDateTime.now(ZoneId.of("America/New_York"))
const startOfTodayInNYC = nowInNewYorkCity.truncatedTo(ChronoUnit.DAYS);
console.log(startOfTodayInNYC.toString()) // Prints "2019-04-15T00:00-04:00[America/New_York]"
// And if you want to print it in ISO format
console.log(startOfTodayInNYC.format(DateTimeFormatter.ISO_INSTANT)) // "2019-04-14T04:00:00Z"
Option 2: Sie kennen den genauen Tag, für den Sie die Uhrzeit erhalten möchten
Dann können Sie die folgenden Methoden von LocalDate verwenden, um die gewünschte relative Zeit (dh ZonedDateTime) abzuleiten:
Option 3: Ich möchte nur den Tag, an dem der Moment eingetreten ist
Beachten Sie, dass Sie mit diesem Code den Tag erhalten, der relativ zu Ihrem Standort ist. Für diejenigen in New York City ist es also „2019-04-14“ und für diejenigen in London wäre es „2019-04-15“ (was großartig ist!), da der Zeitpunkt in dem Zeitraum lag, in dem er sich befindet tatsächlich morgen in London (“2019-04-15T00:00:05Z”). Stellen Sie sich vor, Sie würden jemanden in London von NYC aus anrufen, und der Londoner würde sagen: “Meine Güte, warum rufen Sie mich so früh an … es ist 5 Sekunden nach Mitternacht.”
begin = d
// Go to previous or same Sunday
.with(TemporalAdjusters.previousOrSame(DayOfWeek.SUNDAY))
// Beginning of day
.truncatedTo(ChronoUnit.DAYS)
end = d
// Go to next Sunday
.with(TemporalAdjusters.next(DayOfWeek.SUNDAY))
// Beginning of day
.truncatedTo(ChronoUnit.DAYS)
Ich halte es auch für eine schlechte Idee, das Ende des Wochenintervalls mit darzustellen wenig Zeit vor dem eigentlichen, exklusiven Ende. Es ist besser, begin als inklusive und end als exclusive zu behandeln (bei Vergleichen usw.).
10927100cookie-checkJodatime Tagesbeginn und Tagesendeyes
Es ist immer ein sehr schlechte Idee, eine “kleine Einheit” vom Ende der Zeitintervalle abzuziehen. Zeitintervalle haben ihren Beginn eingeschlossen und ihr Ende ausgeschlossen. Überprüfen Sie, ob eine (Datums-)Zeit in dem Intervall enthalten ist, das Sie tun: Start <= Zeit && Zeit < Ende. Andernfalls erhalten Sie am Ende eine kleine Anzahl von Werten (eigentlich im Intervall), die plötzlich ausgeschlossen werden. Denken Sie in Ihrem Fall an die letzte Sekunde. 23:59:59,5 liegt nicht in diesem Intervall. Die Verwendung kleiner Einheiten verringert nur die Anzahl der ausgeschlossenen Werte, beseitigt das Problem jedoch nicht. Mit dem richtigen Vergleich tut es.
– Mikkel R. Lund
23. April 2019 um 8:28 Uhr