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,
If you want to voluntarily mix Date and DateTime in your application
(see under "should evidently go DateTime all the way"), then you will
have to know that if you compare the two, 00:00:00 will be the assumed
time for Date objects, yes. This is what I called a constructed example
below, becaus
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 gener
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 wit
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
Well, one example:
A campaign price is valid for the duration of January 2022.
In terms of LocalDate, this could be expressed as from 2022-01-01
(inclusive) to 2022-01-31 (inclusive).
In terms of LocalDateTime, this could be expressed as from 2022-01-01 at
midnight (inclusive) to 2022-02-01
Is the year 2001 "before" the date 2001-06-01? I'd say no, I'd say the year
2001 "contains" any date with year = 2001 so it cannot be logically
"before" or "after" it. Suppose you're sorting people by birth date, and
they can enter either the full date or just the year. How would you
meaningfully c
A day, year, etc is evidently never equal to an actual point in time,
since it is an interval. The question for me is: Can we convert the Date
to a DateTime so that it has an ordering which is helpful/meaningful in
practice, without inviting unexpected bugs etc ?
So what concrete scenario do y
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
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
1. Implicitly attach Time to Date
2. Fill Time with zeroes
3. There you go
On 18/11/2021 15:45, h...@abula.org wrote:
Re. 5:
But there is nothing to fill up with zeroes...
BR;H2
Den 2021-11-18 15:11, skrev MG:
I don't think that is correct: Time intervals for days, etc always
need to be cho
Re. 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
I don't think that is correct: Time intervals for days, etc always need
to be chosen so they are overlap free*, i.e. mathematically speaking the
interval is closed on one end and open on the other, with the start of
the next interval being the end of the last:
[t0,t1[ , [t1,t2[ , ...
For finit
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
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
Well, yea, sure, that is the Java way of doing things: Making every
little bit explicit, leading to non-concise, boiler-plate heavy code
(which is not always good to read either, since all that explicitness
often obsfuscates what is really going on, running counter to the
original intention of
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
17 matches
Mail list logo
