<div dir="auto"><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">BTW, see ThreeTen-Extra for some range and interval classes.</div><div dir="auto"><br></div><div dir="auto">Stephen</div><div dir="auto"><br></div><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 19 Jun 2024, 20:44 Olexandr Rotan, <<a href="mailto:rotanolexandr842@gmail.com">rotanolexandr842@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Greetings to the Java community. I have a question regarding the design of java,time package.<br><br>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! <br><br>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: <br><br>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.<br>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)<br><br>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? <br><br>Would appreciate anything some of you have to share on this topic.<br><br>Best regards</div>
</blockquote></div></div></div>