<p dir="ltr">Sorry to send as follow up, those "to summarize" sentence is a question, not a statement. Sorry for possible confusion </p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 20, 2024, 00:12 Olexandr Rotan <<a href="mailto:rotanolexandr842@gmail.com">rotanolexandr842@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I am aware of 

ThreeTen-Extra. The issue with this library is that it lacks native transition to java.time types, java.time hierarchy is closed and therefore there is no in-all-ways complete way to integrate it in a project without seams all over the place.<br><br>The issue with ranges and comparables is the fact that it is impossible to implement multiple interfaces with different type parameters. This leads to an issue, that, for example, Range<BigDecimal> cant be used against BigInteger, Float, Long etc etc. This is why, I think, this idea in current Java is inherently bad.<br><br>So, to summarize, the main reason why there is no such types in java.time is the fact that there just were tasks with higher priorities at the moment. If so, I might do some research and draft some APIs myself and present it to the Java team to determine whether it is ok or not to continue development in this direction or not.<br><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 19, 2024 at 11:29 PM Stephen Colebourne <<a href="mailto:scolebourne@joda.org" target="_blank" rel="noreferrer">scolebourne@joda.org</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="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" target="_blank" rel="noreferrer">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>
</blockquote></div>
</blockquote></div>