f 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
>> Sent: Wednes
On 18.11.21 15:10, Alessio Stalla wrote:
Dates are not something to mess with lightheartedly. All kinds of weird
exceptions exist. In some dates in some timezones, midnight (i.e. 00:00)
does not exist:
https://stackoverflow.com/questions/18489927/a-day-without-midnight
@groovy.apache.org
Cc: h...@abula.org
Subject: Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime
using built-in operators.
CAUTION: This email originated from outside Edinburgh Napier University. Do not
follow links or open attachments if you doubt the authenticity of the sender
Den 2021-11-18 22:47, skrev MG:
If you want to voluntarily mix Date and DateTime in your application...
I certainly don't!
But that's what sparked this discussion, isn't? Otherwise there would be
no pears and apples to compare in the first place, would there?
I think we made our
If you want to voluntarily mix Date and DateTime in your application
(see under "should evidently go DateTime all the way"), then you will
have to know that if you compare the two, 00:00:00 will be the assumed
time for Date objects, yes. This is what I called a constructed example
below,
I agree, that is exactly what I am trying to say: Yes, a Date is
typically seen as representing the time interval of the whole day. But
if we want to be able to compare it to DateTime objects (as was
requested), can we define a time (because it won't evidently not work
for intervals) in a
Guys,
I might have missed something of importance somewhere for I haven't read the
full thread, so please ignore me if I am repeating something already throughly
debated.
Nevertheless, based on the part I did read, it sort of looks like you perhaps
might possibly have missed that any value
1. What I wrote ("A day, year, etc is evidently never equal to an
actual point in time, since it is an interval. The question for me
is: ...") is already the answer to your first sentence.
2. Scale does matter here, so no, reasoning about years and days is not
the same as days and
Well, one example:
A campaign price is valid for the duration of January 2022.
In terms of LocalDate, this could be expressed as from 2022-01-01
(inclusive) to 2022-01-31 (inclusive).
In terms of LocalDateTime, this could be expressed as from 2022-01-01 at
midnight (inclusive) to 2022-02-01
Is the year 2001 "before" the date 2001-06-01? I'd say no, I'd say the year
2001 "contains" any date with year = 2001 so it cannot be logically
"before" or "after" it. Suppose you're sorting people by birth date, and
they can enter either the full date or just the year. How would you
meaningfully
A day, year, etc is evidently never equal to an actual point in time,
since it is an interval. The question for me is: Can we convert the Date
to a DateTime so that it has an ordering which is helpful/meaningful in
practice, without inviting unexpected bugs etc ?
So what concrete scenario do
Hi!
Yes, I got that, but step 1 breaks it IMHO.
It' just as wrong as assuming that a year is equivalent to New Year's
Day that year (at midnight, even).
Filling up with zeroes works when comparing integer numbers with real
numbers, but that's about it.
For one thing, the integer / real
In our applications we use UTC timestamps/dates wherever possible for
this exact reason.
You should rightfully fear the midnight in local time, and storing local
dates/times in your database should imho be avoided wherever possible,
unless it is just used for human readability debugging
1. Implicitly attach Time to Date
2. Fill Time with zeroes
3. There you go
On 18/11/2021 15:45, h...@abula.org wrote:
Re. 5:
But there is nothing to fill up with zeroes...
BR;H2
Den 2021-11-18 15:11, skrev MG:
I don't think that is correct: Time intervals for days, etc always
need to be
Re. 5:
But there is nothing to fill up with zeroes...
BR;H2
Den 2021-11-18 15:11, skrev MG:
I don't think that is correct: Time intervals for days, etc always
need to be chosen so they are overlap free*, i.e. mathematically
speaking the interval is closed on one end and open on the other,
I don't think that is correct: Time intervals for days, etc always need
to be chosen so they are overlap free*, i.e. mathematically speaking the
interval is closed on one end and open on the other, with the start of
the next interval being the end of the last:
[t0,t1[ , [t1,t2[ , ...
For
Dates are not something to mess with lightheartedly. All kinds of weird
exceptions exist. In some dates in some timezones, midnight (i.e. 00:00)
does not exist:
https://stackoverflow.com/questions/18489927/a-day-without-midnight
These kinds of implicit conversions may look like they simplify
On 17.11.21 20:28, MG wrote:
[...]
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
Well, yea, sure, that is the Java way of doing things: Making every
little bit explicit, leading to non-concise, boiler-plate heavy code
(which is not always good to read either, since all that explicitness
often obsfuscates what is really going on, running counter to the
original intention of
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
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
alDateTime one way or the other, someone is going to need the
> opposite.
>
> -Original Message-
> From: Rachel Greenham
> Sent: Wednesday, November 17, 2021 6:00 AM
> To: dev@groovy.apache.org
> Subject: [EXT] Re: A feature request: comparing LocalDate and
> LocalDa
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 a
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
umption 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
Sent: Wednesday, November 17, 2021 6:00 AM
To:dev@groovy.apache.org
Subject: [EXT] Re: A feature request: comparing LocalDate a
and LocalDateTime
one way or the other, someone is going to need the opposite.
-Original Message-
From: Rachel Greenham
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
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
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
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
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
30 matches
Mail list logo
