You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by "Milles, Eric (TR Technology)" <er...@thomsonreuters.com> on 2021/11/17 16:26:53 UTC
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 and LocalDateTime one way or the other, someone is going to need the opposite.
-----Original Message-----
From: Rachel Greenham <ra...@merus.eu>
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-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 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
rachel@merus.eu
> On 17 Nov 2021, at 11:53, h2gr@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 <ss...@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://urldefense.com/v3/__https://github.com/greendatasoft/groovy/commit/c55d722e6b6ead9d6e0123835c62a5fa4f525ffe__;!!GFN0sa3rsbfR8OLyAw!KhyI7wA8GFkwwtNcALvM2BH8QvscE-vHJ2KEn5ArixujSXGxEsH25P0PE3iVV7Rp-EmACLk$
>>> 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?
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by h2...@abula.org.
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, 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-)
Certainly! Let's! ;-)
BR;H2
> On 18/11/2021 20:40, h2gr@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, h2gr@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, h2gr@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
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by MG <mg...@arscreat.com>.
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, h2gr@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, h2gr@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, h2gr@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
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by h2...@abula.org.
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, h2gr@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, h2gr@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
Re: [EXT] A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by MG <mg...@arscreat.com>.
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 general, meaningful, and least surprise way, so that
the result of the comparison makes sense in some useful scenarios,
without carrying too much danger of introducing erronous behavior ?
So:
1. Can it generally be done ?
2. And then, as always, "risk/reward" / "lifeness vs safeness" ?
Cheers,
mg
On 18/11/2021 22:25, OCsite wrote:
> 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 with a limited
> precision can be, from the full-precision point of view, interpreted
> (at the very least) in two ways:
>
> - either as an interval: 1776 means the whole year, 3 represents the
> whole interval <3,4)
> - or as a precise point, 1776 is 0:00.000 Jan 1 1776; 3 is just 3, any
> number of zero decimal places.
>
> None of these interpretation is „right“ nor „wrong“. It depends on the
> particular application which of them (in which place) it decided to
> use. Based on which the further processing needs to exploit one or
> another approach.
>
> All the best and sorry for the intrusion,
> OC
>
>> On 18 Nov 2021, at 22:13, MG <mg...@arscreat.com> wrote:
>>
>> 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.
>> 3. I am not talking about all possible applications, see under
>> "...should evidently go DateTime all the way".
>> 4. By your general logic, float should never be comparable to
>> double, since from the view of double, float is an interval
>> containing all the double precision ("digits") float is missing.
>> Then BigDecimal shows up... :-)
>>
>>
>> On 18/11/2021 18:55, Alessio Stalla wrote:
>>> 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 compare someone who is born "in
>>> 2001" with someone who is born "in 2001-06-01"? It makes no sense to
>>> equate "born in 2001" with "born on Jan 1st, 2001". I'm using year
>>> and day because it's easier to reason about but it's the same for
>>> date and time. A date is an entire day, it's any point within that
>>> day. It's not equal to midnight, at least, not in general, not in
>>> all possible applications. Conflating the two just because it
>>> happens to work for some applications is just bad design imho.
>>>
>>> On Thu, 18 Nov 2021 at 17:43, MG <mg...@arscreat.com> 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: 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, h2gr@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, h2gr@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
>>>
>>
>
Re: [EXT] A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by OCsite <oc...@ocs.cz>.
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 with a limited precision can be, from the full-precision point of view, interpreted (at the very least) in two ways:
- either as an interval: 1776 means the whole year, 3 represents the whole interval <3,4)
- or as a precise point, 1776 is 0:00.000 Jan 1 1776; 3 is just 3, any number of zero decimal places.
None of these interpretation is „right“ nor „wrong“. It depends on the particular application which of them (in which place) it decided to use. Based on which the further processing needs to exploit one or another approach.
All the best and sorry for the intrusion,
OC
> On 18 Nov 2021, at 22:13, MG <mg...@arscreat.com> wrote:
>
> 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.
> Scale does matter here, so no, reasoning about years and days is not the same as days and seconds.
> I am not talking about all possible applications, see under "...should evidently go DateTime all the way".
> By your general logic, float should never be comparable to double, since from the view of double, float is an interval containing all the double precision ("digits") float is missing. Then BigDecimal shows up... :-)
>
> On 18/11/2021 18:55, Alessio Stalla wrote:
>> 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 compare someone who is born "in 2001" with someone who is born "in 2001-06-01"? It makes no sense to equate "born in 2001" with "born on Jan 1st, 2001". I'm using year and day because it's easier to reason about but it's the same for date and time. A date is an entire day, it's any point within that day. It's not equal to midnight, at least, not in general, not in all possible applications. Conflating the two just because it happens to work for some applications is just bad design imho.
>>
>> On Thu, 18 Nov 2021 at 17:43, MG <mgbiz@arscreat.com <ma...@arscreat.com>> 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: 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:
>> 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) ?
>> 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, h2gr@abula.org <ma...@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, h2gr@abula.org <ma...@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
>>
>
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by MG <mg...@arscreat.com>.
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.
3. I am not talking about all possible applications, see under
"...should evidently go DateTime all the way".
4. By your general logic, float should never be comparable to double,
since from the view of double, float is an interval containing all
the double precision ("digits") float is missing. Then BigDecimal
shows up... :-)
On 18/11/2021 18:55, Alessio Stalla wrote:
> 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 compare someone who is born "in 2001" with
> someone who is born "in 2001-06-01"? It makes no sense to equate "born
> in 2001" with "born on Jan 1st, 2001". I'm using year and day because
> it's easier to reason about but it's the same for date and time. A
> date is an entire day, it's any point within that day. It's not equal
> to midnight, at least, not in general, not in all possible
> applications. Conflating the two just because it happens to work for
> some applications is just bad design imho.
>
> On Thu, 18 Nov 2021 at 17:43, MG <mg...@arscreat.com> 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: 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, h2gr@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, h2gr@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
>
RE: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by "Kerridge, Jon" <J....@napier.ac.uk>.
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 as numerical values is wrong and dangerous. For example if we consider the transition from BC to AD or more correctly BCE to CE then 1 BCE is followed by 1 CE there is no ‘year’ ‘zero’. However, some people think there is a year zero and create images that show it.
We introduced the concept of an interval to overcome the problems of doing date and time arithmetic caused by the variability in the number of days in a month. This becomes even more ‘interesting’ when time-zones and day-light saving aspects are included.
Making what appear to be simple changes to a well developed package can have unforeseen consequences and can lead to anomalies like a month having 30.???? days to overcome the fact that months have different numbers of days, which was one solution adopted by a major database system supplier, prior to the implementation of the standard.
One developer’s concept of a month is not the same as another’s. It took many years and many hours of discussion before the SQL standard for Date Time Interval and Time-zone was accepted. Making ‘quick’ changes is not a good idea.
Jon Kerridge
From: Alessio Stalla <al...@gmail.com>
Sent: 18 November 2021 17:55
To: dev@groovy.apache.org
Cc: h2gr@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 content.
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 compare someone who is born "in 2001" with someone who is born "in 2001-06-01"? It makes no sense to equate "born in 2001" with "born on Jan 1st, 2001". I'm using year and day because it's easier to reason about but it's the same for date and time. A date is an entire day, it's any point within that day. It's not equal to midnight, at least, not in general, not in all possible applications. Conflating the two just because it happens to work for some applications is just bad design imho.
On Thu, 18 Nov 2021 at 17:43, MG <mg...@arscreat.com>> 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: 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, h2gr@abula.org<ma...@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, h2gr@abula.org<ma...@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
This message and its attachment(s) are intended for the addressee(s) only and should not be read, copied, disclosed, forwarded or relied upon by any person other than the intended addressee(s) without the permission of the sender. If you are not the intended addressee you must not take any action based on this message and its attachment(s) nor must you copy or show them to anyone. Please respond to the sender and ensure that this message and its attachment(s) are deleted.
It is your responsibility to ensure that this message and its attachment(s) are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this message or its attachment(s), or for errors or omissions arising after it was sent. Email is not a secure medium. Emails entering Edinburgh Napier University's system are subject to routine monitoring and filtering by Edinburgh Napier University.
Edinburgh Napier University is a registered Scottish charity. Registration number SC018373
BSL users can contact us via contactSCOTLAND-BSL, the on-line British Sign Language interpreting service. Find out more on the contactSCOTLAND website.
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by Alessio Stalla <al...@gmail.com>.
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 compare someone who is born "in 2001" with someone who is born
"in 2001-06-01"? It makes no sense to equate "born in 2001" with "born on
Jan 1st, 2001". I'm using year and day because it's easier to reason about
but it's the same for date and time. A date is an entire day, it's any
point within that day. It's not equal to midnight, at least, not in
general, not in all possible applications. Conflating the two just because
it happens to work for some applications is just bad design imho.
On Thu, 18 Nov 2021 at 17:43, MG <mg...@arscreat.com> 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: 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, h2gr@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, h2gr@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
>
>
>
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by MG <mg...@arscreat.com>.
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, h2gr@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, h2gr@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
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by h2...@abula.org.
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, h2gr@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
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by MG <mg...@arscreat.com>.
1. Implicitly attach Time to Date
2. Fill Time with zeroes
3. There you go
On 18/11/2021 15:45, h2gr@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
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by h2...@abula.org.
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
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by MG <mg...@arscreat.com>.
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
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by Jochen Theodorou <bl...@gmx.org>.
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
> <https://stackoverflow.com/questions/18489927/a-day-without-midnight>
> These kinds of implicit conversions may look like they simplify things
> but actually they hide nasty bugs under the carpet, that you'll only
> discover when it's Jan 1st 2031 and you get angry calls in the morning
> while you're hungover, or when your first customer who was born at, I
> don't know, 1978-08-01 at midnight in the Fiji islands signs up into the
> application.
> Please, don't do that. MySQL did that, and I've already suffered because
> of it.
I learned that everything with Strings and times/dates/resources/outputs
for multiple languages/regions are not to underestimate ;)
But this here is really news to me... wow
bye Jochen
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by MG <mg...@arscreat.com>.
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.
I don't however see this Groovy extension to lead to the problems you
allude to, it is just for the case when you have a Date, you can still
compare it conveniently to a DateTime, store them together in a sorted
collection with some plausible default behavior, etc.
As I have said before, nobody is suggesting you start building your
application mixing Date and DateTime objects for the heck of it, it
would in my eyes just be if you do not control the return value of a
call, legacy reasons, stuff like that.
Cheers,
mg
On 18/11/2021 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
> These kinds of implicit conversions may look like they simplify things
> but actually they hide nasty bugs under the carpet, that you'll only
> discover when it's Jan 1st 2031 and you get angry calls in the morning
> while you're hungover, or when your first customer who was born at, I
> don't know, 1978-08-01 at midnight in the Fiji islands signs up into
> the application.
> Please, don't do that. MySQL did that, and I've already suffered
> because of it.
>
> On Thu, 18 Nov 2021 at 14:22, Jochen Theodorou <bl...@gmx.org> 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
>
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by Alessio Stalla <al...@gmail.com>.
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 but
actually they hide nasty bugs under the carpet, that you'll only discover
when it's Jan 1st 2031 and you get angry calls in the morning while you're
hungover, or when your first customer who was born at, I don't know,
1978-08-01 at midnight in the Fiji islands signs up into the application.
Please, don't do that. MySQL did that, and I've already suffered because of
it.
On Thu, 18 Nov 2021 at 14:22, Jochen Theodorou <bl...@gmx.org> 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
>
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by MG <mg...@arscreat.com>.
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 that midnight is by far least suprise, with noon the
only other contender, but one that is imho far behind in 2nd place.
On 17/11/2021 20:49, Milles, Eric (TR Technology) wrote:
>
> 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 = [LocalDate.of(2020, 12, 31), LocalDateTime.of(2020, 12, 31,
> 0, 0, 0), LocalDateTime.of(2020, 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 <mg...@arscreat.com>
> *Sent:* Wednesday, November 17, 2021 1:29 PM
> *To:* dev@groovy.apache.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
> could be very handy.
> 2. Using theLocalDate.atStartOfDay() < theLocalDateTime only works if
> the comparison is done explicitly, but not when e.g. having a sort
> order inside a collection or any order kind of implicit comparison
> of two values (Comparator objects can be used to work around that,
> but that is often quite inconvenient, and might not be possible if
> the collection is not under your control).
> 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 ?
> If someone actually wants a Date to carry e.g. noon as its time, I
> think it is so unusual that I would recommend to make this
> explicit by not using Date objects at all, but instead only
> DateTime objects with the "Date" objects having time = noon
> explicitly set.
> 4. A Time object does naturally not carry any Date information,
> either explicit or implied, since it is the more detailed part of
> the information one needs to pinpoint a point in time. I would
> also not make Local time and zoned time, etc comparable, since
> that is dangerous. Both examples are imho not comparable to the
> situation of making LocalDate and LocalDateTime comparable, since
> I see very little chance of bugs being introduced or "least
> suprise" being violated by this.
>
> Given these assumptions, I would right now see no harm in supplying
> this functionality.
>
> Cheers,
> mg
>
> On 17/11/2021 17:26, Milles, Eric (TR Technology) wrote:
>
> 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 and LocalDateTime one way or
> the other, someone is going to need the opposite.
>
> -----Original Message-----
>
> From: Rachel Greenham <ra...@merus.eu> <ma...@merus.eu>
>
> 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-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 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.
>
RE: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by "Milles, Eric (TR Technology)" <er...@thomsonreuters.com>.
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 = [LocalDate.of(2020, 12, 31), LocalDateTime.of(2020, 12, 31, 0, 0, 0), LocalDateTime.of(2020, 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 <mg...@arscreat.com>
Sent: Wednesday, November 17, 2021 1:29 PM
To: dev@groovy.apache.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 could be very handy.
2. Using theLocalDate.atStartOfDay() < theLocalDateTime only works if the comparison is done explicitly, but not when e.g. having a sort order inside a collection or any order kind of implicit comparison of two values (Comparator objects can be used to work around that, but that is often quite inconvenient, and might not be possible if the collection is not under your control).
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 ? If someone actually wants a Date to carry e.g. noon as its time, I think it is so unusual that I would recommend to make this explicit by not using Date objects at all, but instead only DateTime objects with the "Date" objects having time = noon explicitly set.
4. A Time object does naturally not carry any Date information, either explicit or implied, since it is the more detailed part of the information one needs to pinpoint a point in time. I would also not make Local time and zoned time, etc comparable, since that is dangerous. Both examples are imho not comparable to the situation of making LocalDate and LocalDateTime comparable, since I see very little chance of bugs being introduced or "least suprise" being violated by this.
Given these assumptions, I would right now see no harm in supplying this functionality.
Cheers,
mg
On 17/11/2021 17:26, Milles, Eric (TR Technology) wrote:
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 and LocalDateTime one way or the other, someone is going to need the opposite.
-----Original Message-----
From: Rachel Greenham <ra...@merus.eu>
Sent: Wednesday, November 17, 2021 6:00 AM
To: dev@groovy.apache.org<ma...@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 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.
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by MG <mg...@arscreat.com>.
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 explicitly, but not when e.g. having a sort
order inside a collection or any order kind of implicit comparison
of two values (Comparator objects can be used to work around that,
but that is often quite inconvenient, and might not be possible if
the collection is not under your control).
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 ?
If someone actually wants a Date to carry e.g. noon as its time, I
think it is so unusual that I would recommend to make this explicit
by not using Date objects at all, but instead only DateTime objects
with the "Date" objects having time = noon explicitly set.
4. A Time object does naturally not carry any Date information,
either explicit or implied, since it is the more detailed part of
the information one needs to pinpoint a point in time. I would also
not make Local time and zoned time, etc comparable, since that is
dangerous. Both examples are imho not comparable to the situation of
making LocalDate and LocalDateTime comparable, since I see very
little chance of bugs being introduced or "least suprise" being
violated by this.
Given these assumptions, I would right now see no harm in supplying this
functionality.
Cheers,
mg
On 17/11/2021 17:26, Milles, Eric (TR Technology) wrote:
> 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 and LocalDateTime one way or the other, someone is going to need the opposite.
>
> -----Original Message-----
> From: Rachel Greenham<ra...@merus.eu>
> 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-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 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.
>
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by Paul King <pa...@asert.com.au>.
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 other preferences, they could define their own
"atMidday", "atCloseOfBusiness" or make use of "isBefore" or
"isAfter". So, the core codebase can avoid making any such
assumptions.
Cheers, Paul.
On Thu, Nov 18, 2021 at 6:55 AM ssz <ss...@gmail.com> wrote:
>
> 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(42)``` works for me (in tests)
> if the extension-method has signature `public static int compareTo(LocalDateTime self, LocalDate other)`
> (but does not work if the signature is `public static int compareTo(LocalDateTime self, Object other)`).
>
> Maybe it is worth creating a test for "compareTo-extension" to fixate that behavior?
> (I'd rather expect the second signature to work, rather than the first one)
>
> In any case, I think, this does not cancel the original question,
> ...
> As for the example with the list, I don't see a problem here: we are comparing `LocalDate#atStartOfDay` with `LocalDateTime`, not `LocalDate` with `LocalDateTime#toLocalDate()`, so there is no losing information -> no ambiguities -> it should be pretty safe.
>
>
> On Wed, Nov 17, 2021 at 7:27 PM Milles, Eric (TR Technology) <er...@thomsonreuters.com> wrote:
>>
>> 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 and LocalDateTime one way or the other, someone is going to need the opposite.
>>
>> -----Original Message-----
>> From: Rachel Greenham <ra...@merus.eu>
>> 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-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 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
>> rachel@merus.eu
>>
>>
>>
>> > On 17 Nov 2021, at 11:53, h2gr@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 <ss...@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://urldefense.com/v3/__https://github.com/greendatasoft/groovy/commit/c55d722e6b6ead9d6e0123835c62a5fa4f525ffe__;!!GFN0sa3rsbfR8OLyAw!KhyI7wA8GFkwwtNcALvM2BH8QvscE-vHJ2KEn5ArixujSXGxEsH25P0PE3iVV7Rp-EmACLk$
>> >>> 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?
>>
Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.
Posted by ssz <ss...@gmail.com>.
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(42)``` works for me (in tests)
if the extension-method has signature `public static int
compareTo(LocalDateTime self, LocalDate other)`
(but does not work if the signature is `public static int
compareTo(LocalDateTime self, Object other)`).
Maybe it is worth creating a test for "compareTo-extension" to fixate that
behavior?
(I'd rather expect the second signature to work, rather than the first one)
In any case, I think, this does not cancel the original question,
...
As for the example with the list, I don't see a problem here: we are
comparing `LocalDate#atStartOfDay` with `LocalDateTime`, not `LocalDate`
with `LocalDateTime#toLocalDate()`, so there is no losing information -> no
ambiguities -> it should be pretty safe.
On Wed, Nov 17, 2021 at 7:27 PM Milles, Eric (TR Technology) <
eric.milles@thomsonreuters.com> wrote:
> 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
> and LocalDateTime one way or the other, someone is going to need the
> opposite.
>
> -----Original Message-----
> From: Rachel Greenham <ra...@merus.eu>
> 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-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 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
> rachel@merus.eu
>
>
>
> > On 17 Nov 2021, at 11:53, h2gr@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 <ss...@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://urldefense.com/v3/__https://github.com/greendatasoft/groovy/commit/c55d722e6b6ead9d6e0123835c62a5fa4f525ffe__;!!GFN0sa3rsbfR8OLyAw!KhyI7wA8GFkwwtNcALvM2BH8QvscE-vHJ2KEn5ArixujSXGxEsH25P0PE3iVV7Rp-EmACLk$
> >>> 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?
>
>