There is discussion of LocalDate comparing equal to LocalDateTime for the entire span of the day or being equal only for the instant of midnight. If compare logic is changed, then so to is equality logic for == operator.
So I'll create a concrete example just to help things along. def list = [LocalDate.of(2020, 12, 31), LocalDateTime.of(2020, 12, 31, 0, 0, 0), LocalDateTime.of(2020, 12, 31, 0, 0, 1)] list.sort(true) How should list be sorted? 0 and 1 are the same, right. Is 2 greater than 0 or the same? From: MG <mg...@arscreat.com> Sent: Wednesday, November 17, 2021 1:29 PM To: dev@groovy.apache.org Subject: Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators. From the top of my hat (as always I am ready to be proven wrong by counter examples / arguments :-) ): 1. While we don't need that feature ourselves right now, I think it could be very handy. 2. Using theLocalDate.atStartOfDay() < theLocalDateTime only works if the comparison is done explicitly, but not when e.g. having a sort order inside a collection or any order kind of implicit comparison of two values (Comparator objects can be used to work around that, but that is often quite inconvenient, and might not be possible if the collection is not under your control). 3. I have never encountered any other assumption than the one that a Date carries the implicit time of midnight (00:00:00.000...). What other time would one logically pick, given that time intervals are by convention typically closed on the left and open on the right ? If someone actually wants a Date to carry e.g. noon as its time, I think it is so unusual that I would recommend to make this explicit by not using Date objects at all, but instead only DateTime objects with the "Date" objects having time = noon explicitly set. 4. A Time object does naturally not carry any Date information, either explicit or implied, since it is the more detailed part of the information one needs to pinpoint a point in time. I would also not make Local time and zoned time, etc comparable, since that is dangerous. Both examples are imho not comparable to the situation of making LocalDate and LocalDateTime comparable, since I see very little chance of bugs being introduced or "least suprise" being violated by this. Given these assumptions, I would right now see no harm in supplying this functionality. Cheers, mg On 17/11/2021 17:26, Milles, Eric (TR Technology) 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><mailto:rac...@merus.eu> Sent: Wednesday, November 17, 2021 6:00 AM To: dev@groovy.apache.org<mailto: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.
