Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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 have

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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

RE: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

@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 or the

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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 points,

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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, becaus

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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 seconds

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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 c

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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 y

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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 num

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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 purposes

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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 cho

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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, with

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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 finit

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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 things

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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 and

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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() < java.time.LocalDate.now().plusDays(

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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 *Sent:* Wednesday, November 17, 2021 1:29 PM *To:* dev@groovy.apache.org *Subject:* Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime

RE: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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

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 expli

RE: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

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