Hi, I think using an extension module is the way to go for your use case. I merged your proposed PR with the test which ensures that such an extension can be defined (as you'd know but for clarification to others).
Some folks might prefer the call to "atStartOfDay" to be explicit. Some might have other preferences, they could define their own "atMidday", "atCloseOfBusiness" or make use of "isBefore" or "isAfter". So, the core codebase can avoid making any such assumptions. Cheers, Paul. On Thu, Nov 18, 2021 at 6:55 AM ssz <sss.z...@gmail.com> wrote: > > Indeed, it seems our issue can be solved with the existing built-in > mechanisms (I didn't know that). > Looks like we can override java methods in groovy with help of > `org.codehaus.groovy.runtime.ExtensionModule`. > The script ```assert java.time.LocalDateTime.now() < > java.time.LocalDate.now().plusDays(42)``` works for me (in tests) > if the extension-method has signature `public static int > compareTo(LocalDateTime self, LocalDate other)` > (but does not work if the signature is `public static int > compareTo(LocalDateTime self, Object other)`). > > Maybe it is worth creating a test for "compareTo-extension" to fixate that > behavior? > (I'd rather expect the second signature to work, rather than the first one) > > In any case, I think, this does not cancel the original question, > ... > As for the example with the list, I don't see a problem here: we are > comparing `LocalDate#atStartOfDay` with `LocalDateTime`, not `LocalDate` with > `LocalDateTime#toLocalDate()`, so there is no losing information -> no > ambiguities -> it should be pretty safe. > > > On Wed, Nov 17, 2021 at 7:27 PM Milles, Eric (TR Technology) > <eric.mil...@thomsonreuters.com> wrote: >> >> Is there a path forward where the language runtime does not need to embed >> this handling, but the extension mechanisms in place can be used by your >> project so your users get the ease of comparison of these two types? As >> soon as Groovy takes on the assumption that it is okay to compare LocalDate >> and LocalDateTime one way or the other, someone is going to need the >> opposite. >> >> -----Original Message----- >> From: Rachel Greenham <rac...@merus.eu> >> Sent: Wednesday, November 17, 2021 6:00 AM >> To: dev@groovy.apache.org >> Subject: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime >> using built-in operators. >> >> External Email: Use caution with links and attachments. >> >> 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://urldefense.com/v3/__https://github.com/greendatasoft/groovy/commit/c55d722e6b6ead9d6e0123835c62a5fa4f525ffe__;!!GFN0sa3rsbfR8OLyAw!KhyI7wA8GFkwwtNcALvM2BH8QvscE-vHJ2KEn5ArixujSXGxEsH25P0PE3iVV7Rp-EmACLk$ >> >>> 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? >>
