There are a variety of ways that a range of the timeline can be defined. And some would argue that Java should have a general purpose Range class to cover all Comparable classes rather than a few specific ones for Java time.
Ultimately, Java time chose to avoid the issues by not addressing the design space. There were plenty of other things to tackle at the time. BTW, see ThreeTen-Extra for some range and interval classes. Stephen On Wed, 19 Jun 2024, 20:44 Olexandr Rotan, <rotanolexandr...@gmail.com> wrote: > Greetings to the Java community. I have a question regarding the design of > java,time package. > > Commercial Java developers deal with time periods all the time with > different validations regarding intersection of periods, big data > processing, entity auditing etc etc. And it is surprising for everyone to > look into java.time for the first time and find out that there is no start > and end aware span data types at all! > > There is no rocket science in implementing such data types yourself, > that's for sure. However, as always, there are hidden spikes in these > waters.To use these types in JPA entities, you would have to write a custom > converter to familiar for database type, which ties project tightly to > database, which is contrary to what JPA was intended for . To use it in > auditing. one would have to write a custom auditor as no framework or > library knows about our custom data type. Same goes for big data > processing: no library or framework would support processing series of your > custom data type, at least unless you provide some adapter using library > mechanisms, if those exist at all. This rant could go on and on, but the > points are: > > 1) Lack of standardization for such data types leads to obstacles on each > step of development: constant writing of adapters, converters and blah blah > blah. Each of those serves as a space to make mistakes. One-two easy > implementations are not likely to be the source of errors, but the more a > project grows, the more dependencies it acquires, the more it is likely to > fall for some subtle specific feature of some library and spend hours or > even days debugging. > 2) One could rightfully argue that for small projects or microservice > projects with no shared codebase and different team for each service, this > whole mess I described above is overengineering. Seriously, not everyone > would want to go through all of that for one-two usages of class in the > domain layer of the project, and, moreover, not everyone should. However, > leaving it be "as is" is a screaming source of data inconsistencies, as it > is now responsibility of developer (or even worse, user) to keep in mind > the requirement to update all fields, that combined form that start- and > end-aware period (like start date/datetime and Period/Duration as common > way to emulate such thing) > > So, the question is: was it a conscious decision to omit such types back > in the day when java.time was designed, or is it a blindspot created by > deadlines/lack of resources/something else? > > Would appreciate anything some of you have to share on this topic. > > Best regards >
