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

[MG]

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, because you try to create a problem that would not be there, if 
you did not insist on the one interval being inclusive; in general it is 
as bad an idea to mix inclusive and exclusive intervals as, as it is to 
mix 0 and 1 based index access, or to not do all your calculations in a 
single reference frame in special/general relativity...

I think we made our points, I suggest we wait what Mr. Groovy (aka Paul) 
has to say, who might easily shoot this down with an argument no one has 
yet considered... G-)

Cheers,
mg


On 18/11/2021 20:40, h...@abula.org wrote:
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 at midnight (exclusive).

Note the difference with the to-date being inclusive while the 
to-datetime being exclusive.

This makes sense because a date has a resolution of one day and thus 
contains all times within that day.

Yes, one could argue, but then again - ask a user who might define 
such a campaign price's valid period what is "right" for them, and try 
to explain why it has to be different (i.e. inclusive/exclusive 
because of code concerns.

BR;H2

Den 2021-11-18 17:42, skrev MG:
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 you see where the implicit attaching of
00:00:00 to a Date for the sake of comparison:

1.   Leads to a program error in a practical scenario (i.e. not
   constructed and not for applications which control their data types
   and should evidently go DateTime all the way) ?
2. Leads to an unexpected result, i.e. "does not work for the developer
   or user" ?

You might assume I am dead set on getting this into Groovy, but that
is not the case. It is just that the counter arguments I have seen to
this point seemed quite weak to me, so I have taken the position to
argue for it (wich is the direction I am leaning to) - but convince me
otherwise (saying "it is just wrong on principal" won't do that,
though, unless I buy into your principle, which I oftend do not, since
for me what is relevant is mostly whether it works in practice).

Cheers,
mg

PS:  The "filling with zeroes" was a fluff comment - that's why it is
in brackets and has an according smiley at the end ;-)



On 18/11/2021 16:25, h...@abula.org wrote:
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 number comparison works both ways. 
The same cannot be said about LocalDateTime and LocalDate.

Sorry...

BR;H2

Den 2021-11-18 16:01, skrev MG:
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 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 finite resolution (i.e. computers; assuming 3 didgits of
millisecond precision) and the example of 1 day as interval length,
this would mean that the interval of a day looks like:
[date 00:00:00.000, date 23:59:59.999]
or
[date 00:00:00.000, date+1 00:00:00.000[

To sum up:

1. I have used the convention to chose the start of the interval 
to be
   closed, and the end to be open (i.e. t0 is in the interval, 
whereas
   t1 is not), which I have encountered time and time again, and
   therefore assume to be widely used.
2. Using midnight of the following day only makes sense if you 
invert
   the open-closed end of the interval, which as I said to me is 
quite
   unusal.
3. Using an application dependent time such as 21:00, 23:00, 01:00,
   02:00 or 08:00 (because that is "when the backup runs or has
   finished") is certainly something which no one can expect to 
be the
   convention in a generally used language, and would imho be a
   terrible idea (apart from the fact that there is no concept on 
how
   to choose one over the other). It would also violate the sort 
order
   of Date with DateTime, in the most unexpected way. 
Applications that
   want/need that will have to use DateTime throughout.
4. As I have said, the only other implicit time I would consider
   slightly viable is noon, but as far as least surprise, sort order
   behavior, etc goes, using the start of the day is imho the 
singular
   choice.
5. (Using 00:00:00.000 also follows the time honored IT 
convention of
   "filling things up with zeroes", if not explicitly told 
differently
   ;-) )

Cheers,
mg

*Otherwise a point in time could be in more than one interval (e.g.
belong to more than one day).


On 18/11/2021 14:22, Jochen Theodorou wrote:
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 open on the 
right ?

But you have here already trouble. you can take the start of the 
day, or
the end of the day. both is midnight, both based on the same 
date, but
they are basically 24h apart. In my last project we mostly used 
end of
the day for example. And in some parts actually 2:00 in the 
morning,
because it is the time to run after some processes... which did not
proof to be a good idea btw.

bye Jochen