Podam to co napisałem dla naszego zespołu jako odpowiedź używając linku Voo do czasu aż Voo doda odpowiedź, wtedy dam mu kredyt. Oto co postanowiłem dla naszej sprawy:

Przedziały czasowe w naszych aplikacjach będą reprezentowane jako para chwilowe czasy z konwencją, że czas rozpoczęcia jest inclusive i czas zakończenia jest wyłączny. Konwencja ta jest matematycznie wygodne, gdyż różnica granic jest równa długości interwał, a także jest numerycznie zgodny ze sposobem zapisu tablic i list w Javie programy (Zobacz http://www.cs.utexas.edu / ~ EWD / ewd08xx / EWD831. PDF ). The 2012-03-17T00:00:00.000 Z – 2012-03-18T00:00:00.000 Z, i każda data rozpoczynająca się od 2012-03-17 będzie oznaczona jako wliczone w Dzień Świętego Patryka, ale 2012-03-18T00:00:00.000 Z nie będzie wliczony, a Dzień Św. Patryka będzie Dołącz dokładnie 24*60*60*1000 milisekundy.

Nie mogę powiedzieć na pewno, ale wątpię, że istnieje norma lub konwencja. To, czy włączysz pocztę początkową lub końcową, zależy od Twojego przypadku użycia, więc zastanów się, czy są one dla Ciebie ważne. Jeśli decyzja jest arbitralna, wybierz jedną, zauważ, że wybór jest arbitralny i idź dalej.

Co do tego, co jest obsługiwane w Javie, biblioteka czasu Joda implementuje Intervals, które zawierają czas rozpoczęcia, ale nie czas zakończenia

Pomimo tego, że ten wątek skupia się bardziej na Javie, pomyślałem, że byłoby całkiem interesujące zobaczyć inne przyjęte konwencje, zwłaszcza biorąc pod uwagę, że biblioteka pandas Python jest wszechobecna do analizy danych w dzisiejszych czasach, i fakt, że ta strona StackOverflow jest jednym z najlepszych wyników wyszukiwania, Gdy szukasz konwencji dotyczących inkluzywności/wyłączności zakresów czasu.

Cytowanie tej strony:

Daty rozpoczęcia i zakończenia są ściśle inclusive. Więc nie będzie Generuj dowolne daty poza tymi datami, jeśli są określone.

Nie tylko generuje zakresy dat. Konwencja jest również przyjęta przy próbie indeksowania danych szeregów czasowych. Oto prosty test na ramkach danych z DatetimeIndex

>>> import pandas as pd
>>> pd.__version__
'0.20.2'
>>> df = pd.DataFrame(list(range(20)))
>>> df.index = pd.date_range(start="2017-07-01", periods=20)
>>> df["2017-07-01":"2017-07-05"]
            0
2017-07-01  0
2017-07-02  1
2017-07-03  2
2017-07-04  3
2017-07-05  4

Java.time & Half-Open

Java.CZAS klasy, które zastępują kłopotliwe starsze klasy date-time, jak również projekt Joda-Time definiują rozpiętość czasu przy użyciu podejścia półotwartego [), gdzie początek jest inclusive, podczas gdy zakończenie jest exclusive.

Dla daty i czasu z ułamkową sekundą eliminuje to problem próby uchwycenia ostatniej chwili. Nieskończenie podzielna ostatnia sekunda musi być rozwiązana, ale różne systemy używaj różnych ziarnistości, takich jak milisekundy, mikrosekundy, nanosekundy lub coś innego. Na przykład w przypadku Half-Open, dzień zaczyna się w pierwszej chwili dnia i trwa do, ale nie zawiera , a nie, pierwszej chwili następnego dnia. Problem rozwiązany, nie trzeba zmagać się z ostatnią chwilą dnia i jego ułamkową sekundą.

Zacząłem dostrzegać korzyści płynące z konsekwentnego stosowania tego podejścia przez cały mój kod do obsługi daty i czasu. Tydzień np. początek w poniedziałek trwa do, ale nie obejmuje, następnego poniedziałku. Miesiąc rozpoczyna się 1. i trwa do, ale nie obejmuje, pierwszego następnego miesiąca, ignorując tym samym wyzwanie określenia liczby ostatniego dnia miesiąca, w tym 28/29 lutego roku przestępnego.

Kolejną zaletą konsekwentnego stosowania półotwartego [) jest złagodzenie obciążenia poznawczego za każdym razem, gdy muszę wykryć, odszyfrować i zweryfikować fragment kodu w czasie. W moim własnym programowaniu wystarczy spojrzeć na wzmiankę o półotwartym w komentarzu na górze i od razu wiem, jak odczytać ten kod.

Rezultatem konsekwentnego używania półotwartego kodu jest zmniejszenie szansy na błędy w moim kodzie, ponieważ mój styl myślenia i pisania jest jednolity, bez szans na zmieszanie się z wyłącznością.

Przy okazji, zauważ, że półotwarte [) oznacza unikanie kombinacji SQL BETWEEN, ponieważ zawsze jest całkowicie zamknięte [].

Co do biznesowego myślenia klientów I serwować, w razie potrzeby staram się ich przekonać do ciągłego używania półotwartych. Widziałem wiele sytuacji, w których różni biznesmeni robili błędne założenia dotyczące okresów czasu objętych raportami. Konsekwentne stosowanie półotwartych unika tych niefortunnych niejasności. Ale jeśli klient nalega, zaznaczam to w moim kodzie i dostosowuję wejścia/wyjścia tak, aby używać półotwartego w mojej własnej logice. Na przykład moja logika używa tygodnia poniedziałek-poniedziałek, ale w raporcie odjąć dzień, aby pokazać Niedziela.

Jeszcze więcej klas reprezentujących czas z podejściem półotwartym [), zobacz projekt ThreeTen-Extras dla jego klasy Interval (para obiektów Instant) i klasy LocalDateRange (para obiektów {4]}).

O Javie.CZAS

Java.Framework time jest wbudowany w Javę 8 i nowszą. Klasy te zastępują kłopotliwe staredziedzictwo klasy date-time, takie jak java.util.Date, Calendar, & SimpleDateFormat.

Projekt Joda-Time , obecnie w trybie konserwacji , radzi migrację do java.CZAS klasy.

Skąd pobrać Javę.zajęcia czasowe?

• Java SE 8, Java SE 9, oraz później
  • Wbudowany.
  • część standardowego API Javy z dołączoną implementacją.
  • Java 9 dodaje kilka drobnych funkcji i poprawek.
• Java SE 6 oraz Java SE 7
  • Większość Javy.funkcja czasu powraca-przeportowana do Javy 6 i 7 w ThreeTen-Backport.
• Android
  • The ThreeTenABP projekt dostosowuje ThreeTen-Backport (wspomniano powyżej) specjalnie dla Androida.
  • Zobacz Jak stosować ThreeTenABP....

The ThreeTen-Extra projekt rozszerza Javę.czas z dodatkowymi zajęciami. Ten projekt jest poligonem dla potencjalnych przyszłych dodatków do Javy.czas. Możesz znaleźć tutaj kilka przydatnych klas, takich jak Interval, YearWeek, YearQuarter, i więcej .

Właśnie przechodziłem przez ten sam proces myślowy i uważam, że bardzo ważne jest, aby został on w jakiś sposób ustandaryzowany, lub przynajmniej wyjaśniony za pomocą tego typu postów z pytaniami i odpowiedziami!

W naszym przypadku zakresy dat są używane jako wejścia i wyjścia do / Z mikroserwisu; taki, który, przynajmniej krótkoterminowo, zostanie wywołany przez istniejącą aplikację monolityczną (jest to projekt rozkładu monolitu). Dlatego uważam, że powyższy komentarz dotyczący podejmowanie decyzji w oparciu o wymagania biznesowe jest w naszym przypadku mniej istotne (ponieważ bezpośredni "użytkownicy" tworzonego przez nas oprogramowania to naprawdę ludzie techniczni). Gdybyśmy zajmowali się wejściami z selektora DAT, to może być inna historia!

Moim zaleceniem było to, że wszystkie daty rozpoczęcia są inclusive i wszystkie daty zakończenia są wyłączne - więc [A, B)w notacji. Było to z następujących powodów:

1. Wcześniej uzgodniliśmy, że wszelkie nadchodzące daty zawierające części czasu zostaną odrzucone (nawet jeśli wartość JSON to "2018-01-01T00:00:00") i że będziemy wypisywać wszystkie daty bez czasów. Dlatego, jeśli data końcowa jest wyłączna, gdy tylko łańcuch zostanie deserializowany do obiektu. NET DateTime, będzie to dzień.

2. Podoba mi się pomysł, że zakresy dat (które w naszym przypadku powinny zawsze dawać całe dni) można zawsze obliczyć po prostu wykonując dateRange = (endDateExcl - startDateIncl).TotalDays. Nie trzeba dodawać 1 wszędzie!

3. Większość walidacji biznesowej wykonywanej przez usługę polega na sprawdzeniu, czy wiele zakresów danych jest równo ze sobą bez luk. Jest to łatwe do sprawdzenia podczas używania [A, B), ponieważ każde B powinno pasować do poprzedniego A. Jeśli pójdziemy z [A, B], to my (programiści, testerzy, inżynierowie wsparcia) często zadawalibyśmy sobie pytanie " ile dni jest w marcu ponownie?"(np. [2018-03-01,2018-03-30],[2018-04-01,2018-04-30]) albo " czy 2016 ma dzień przestępny?"(np. [2016-02-01,2016-02-28],[2016-03-01,2016-03-30]).

Aby dodać, zdecydowanie polecam każdemu, niezależnie od decyzji, aby wyraźnie przyrostek wszystkich nazw atrybutów, zmiennych, metod lub w inny sposób z "Incl" lub "Excl", aby było jasne dla wszystkich bez konieczności poszukiwania dokumentacji!

Zaleciliśmy również, aby wszystkie daty były w formacie ISO i że wszystko, co ma " Z " na końcu, również powinno być odrzucone (ponieważ zrozumienie jest takie, że jesteśmy praca w ciągu całych dni i nie chcemy, aby data została deserializowana do obiektu DateTime z godziną rogue (lub 23!) ze względu na czas letni).

Przypis, pewnie zamieściłbym to jako komentarz do odpowiedzi Voo, ale właśnie (z opóźnieniem!) dołączył więc i muszę zasłużyć na moje uznanie, zanim będę mógł to zrobić! ;-)

Happy dating x