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