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? > >
