Hi,
I think using an extension module is the way to go for your use case.
I merged your proposed PR with the test which ensures that such an
extension can be defined (as you'd know but for clarification to
others).
Some folks might prefer the call to "atStartOfDay" to be explicit.
Some might
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
Hi,
In a previous life I helped to develop the date time time-zone and interval
concept for the database language SQL. The conversations currently happening
with respect to Groovy/ Java date and time remind me of the problems the SQL
ISO Standard committee had to discuss. Thinking of dates
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,
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
Indeed, it seems our issue can be solved with the existing built-in
mechanisms (I didn't know that).
Looks like we can override java methods in groovy with help of
`org.codehaus.groovy.runtime.ExtensionModule`.
The script ```assert java.time.LocalDateTime.now() <
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
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 =
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
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
21 matches
Mail list logo
