I think this is part of the argument to be had with the *java*.time api (it’s not really a groovy matter tbh). A LocalDate is a time with a resolution of one day, it is not implicitly midnight, just as a LocalTime does not imply *any* day, including today, just a time of day, and a LocalDateTime does not compare to a ZonedDateTime because you really need that zone info, and it could be dangerous to assume a timezone. so the API stops you acting as if that’s ok.
It’s therefore proper to expect to do the conversion. theLocalDate.atStartOfDay() < theLocalDateTime (or theLocalDate.atStartOfDay().isBefore(theLocalDateTime()) ) That’s the conceptual problem with wanting a convenience of being able to compare different time types *without knowing what they are*. It means you may be embedding assumptions in a library that aren’t as global as you might think they are. -- Rachel Greenham rac...@merus.eu > On 17 Nov 2021, at 11:53, h...@abula.org wrote: > >>> Here, we represent `java.time.LocalDate` as a `java.time.LocalDateTime` at >>> midnight. > > Just off the top of my head, should the LocalDate match LocalDateTime only at > midnight? Or should it match any point in time during that date? Surely it's > April fool's day for the entire duration of April 1st? > > BR; Haakon Hansen, Norway > > Den 2021-11-17 12:28, skrev Søren Berg Glasius: >> I think this is a very good idea, and give a +1 for the idea and >> implementation. >> Best regards / Med venlig hilsen, >> Søren Berg Glasius >> Hedevej 1, Gl. Rye, 8680 Ry, Denmark >> Mobile: +45 40 44 91 88, Skype: sbglasius >> --- Press ESC once to quit - twice to save the changes. >> Den tir. 16. nov. 2021 kl. 15.24 skrev ssz <sss.z...@gmail.com>: >>> Hello everyone, >>> Before creating a PR (or\and an issue in Jira) I would like to discuss a >>> possible feature. >>> In our product we need the ability to compare `java.time.LocalDate` and >>> `java.time.LocalDateTime` objects easily without knowing the exact type. >>> For this we have historical reasons: we have a groovy-based engine and a >>> lot of client scripts with date comparison. >>> Until recently, we used a customized version of joda-time, that allows >>> such operations. >>> As practice has shown, it was very convenient. >>> But now for some reasons we have decided to abandon joda-time in favor of >>> pure java-time. >>> So, in order not to break anyone's scripts it would be nice for us if >>> groovy could support comparisons of those date-objects out of the box. >>> To demonstrate what I mean here is a draft: >>> https://github.com/greendatasoft/groovy/commit/c55d722e6b6ead9d6e0123835c62a5fa4f525ffe >>> Here, we represent `java.time.LocalDate` as a `java.time.LocalDateTime` at >>> midnight. >>> It seems this way can't break any code, and at the same time it would be >>> user-friendly. >>> But for those who have weird logic with exception handling, there is a >>> "groovy.compare.local-date-and-datetime" option, which allows to return >>> back the original behaviour. >>> Please tell me what you think. >>> Can I proceed with PR? >>> Or maybe there is a better way to customize groovy to achieve the same >>> behaviour?
