1. "for the entire span of the day" does imho not work, for exactly the
reason you have given :-)
2. The only option in my eyes is to pick a time that is always
implicitly attached to a date.
3. The only question that remains is then the already posed one of:
What time ?
4. Here I argue that midnight is by far least suprise, with noon the
only other contender, but one that is imho far behind in 2nd place.
On 17/11/2021 20:49, Milles, Eric (TR Technology) wrote:
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
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.
