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?
