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,
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
Hi!
Yes, I got that, but step 1 breaks it IMHO.
It' just as wrong as assuming that a year is equivalent to New Year's
Day that year (at midnight, even).
Filling up with zeroes works when comparing integer numbers with real
numbers, but that's about it.
For one thing, the integer / real num
Re. 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
Correction:
Argh.
As you probably already have spotted, I should have written this:
localDateTime.toLocalDate().equals(localDate)
or
localDateTime.toLocalDate() == localDate
Now apples are compared with apples, the non-apple part is ignored, and
nothing is assumed beyond the lowest reso
I think resolution is a key word here, and I agree that it is proper to
be explicit about what one assumes.
That said, if one assumption were to be made, why not compare what is
comparable and not what isn't, e.g.
localDateTime.getDateTime().equals(localDate)
or
localDateTime.dateTime =
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
No. Never.
Are you sure you're not biased in any say? Not even a little? Come on...
Cheers,
Haakon Hansen
The "communist" kingdom of Norway
---
Den 2020-05-21 03:48, skrev MG:
NEVER ? Not even a little ? Come on...
Socialist/communist red star:
Scale horizontally:
Change fill color
See comment below.
Den 2018-08-15 14:55, skrev ocs@ocs:
H2,
On 15 Aug 2018, at 9:47 AM, h...@abula.org wrote:
OCS, your reference to Objective-C is interesting, as is your
expectation for your code to encounter null values often.
In my experience, a null is (should be, at the very least) a
OCS, your reference to Objective-C is interesting, as is your
expectation for your code to encounter null values often.
I may be old school, but I think the semantics of null values is
interesting, as is the semantics of safe navigation.
Safe navigation addresses the matter of nested if state
Den 2018-08-15 00:28, skrev Jennifer Strater:
Hi OC,
First, I agree with Paul and Andres that it would be nice to see how
well this works outside of groovy core. Hopefully, someone here can
help you make it a reality.
In addition, I would really appreciate it, if, in the future, you did
not use
Den 2018-08-14 15:23, skrev ocs@ocs:
H2,
However, “a+b” should work as one would expect
Absolutely. Me, I very definitely expect that if a happens to be null,
the result is null too. (With b null it depends on the details of
a.plus implementation.)
I kind of expected that... :-) I am curiou
Den 2018-08-14 14:25, skrev ocs@ocs:
H2,
On 14 Aug 2018, at 1:38 PM, h...@abula.org wrote:
IMHO, there is an ever so subtle difference between navigation - using
the . operator explictly or implicitly (as with indexing) - and
arithmetic.
do please correct me if I am wrong, but I understand
IMHO, there is an ever so subtle difference between navigation - using
the . operator explictly or implicitly (as with indexing) - and
arithmetic.
I am personally perfectly happy for my arithmetic expressions to fail
with any applicable exception if I throw unacceptable values at them.
H2
Why would anyone subclass Closure? Isn't there enough trouble to be
found elsewhere?
H2
Den 2018-08-08 20:05, skrev Jochen Theodorou:
Hi all,
during JCrete I was playing around with removing some of those
setAccessible calls and found one quite problematic case.
AS many here know we have so
15 matches
Mail list logo
