Correction:
Argh.
As you probably already have spotted, I should have written this:
localDateTime.toLocalDate().equals(localDate)
or
localDateTime.toLocalDate() == localDate
Now apples are compared with apples, the non-apple part is ignored, and
nothing is assumed beyond the lowest resolution.
BR;H2
Den 2021-11-17 21:56, skrev h...@abula.org:
I think resolution is a key word here, and I agree that it is proper
to be explicit about what one assumes.
That said, if one assumption were to be made, why not compare what is
comparable and not what isn't, e.g.
localDateTime.getDateTime().equals(localDate)
or
localDateTime.dateTime == localDate
Doesn't code like this look agreeable enough?
BR; Haakon Hansen, Norway
--
Den 2021-11-17 13:00, skrev Rachel Greenham:
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://github.com/greendatasoft/groovy/commit/c55d722e6b6ead9d6e0123835c62a5fa4f525ffe
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?
