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 <alessiosta...@gmail.com> Sent: 18 November 2021 17:55 To: dev@groovy.apache.org Cc: h...@abula.org Subject: Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators. CAUTION: This email originated from outside Edinburgh Napier University. Do not follow links or open attachments if you doubt the authenticity of the sender or the 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<mailto: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, h...@abula.org<mailto:h...@abula.org> wrote: Hi! Yes, I got that, but step 1 breaks it IMHO. It' just as wrong as assuming that a year is equivalent to New Year's Day that year (at midnight, even). Filling up with zeroes works when comparing integer numbers with real numbers, but that's about it. For one thing, the integer / real number comparison works both ways. The same cannot be said about LocalDateTime and LocalDate. Sorry... BR;H2 Den 2021-11-18 16:01, skrev MG: 1. Implicitly attach Time to Date 2. Fill Time with zeroes 3. There you go On 18/11/2021 15:45, h...@abula.org<mailto:h...@abula.org> wrote: Re. 5: But there is nothing to fill up with zeroes... BR;H2 Den 2021-11-18 15:11, skrev MG: I don't think that is correct: Time intervals for days, etc always need to be chosen so they are overlap free*, i.e. mathematically speaking the interval is closed on one end and open on the other, with the start of the next interval being the end of the last: [t0,t1[ , [t1,t2[ , ... For finite resolution (i.e. computers; assuming 3 didgits of millisecond precision) and the example of 1 day as interval length, this would mean that the interval of a day looks like: [date 00:00:00.000, date 23:59:59.999] or [date 00:00:00.000, date+1 00:00:00.000[ To sum up: 1. I have used the convention to chose the start of the interval to be closed, and the end to be open (i.e. t0 is in the interval, whereas t1 is not), which I have encountered time and time again, and therefore assume to be widely used. 2. Using midnight of the following day only makes sense if you invert the open-closed end of the interval, which as I said to me is quite unusal. 3. Using an application dependent time such as 21:00, 23:00, 01:00, 02:00 or 08:00 (because that is "when the backup runs or has finished") is certainly something which no one can expect to be the convention in a generally used language, and would imho be a terrible idea (apart from the fact that there is no concept on how to choose one over the other). It would also violate the sort order of Date with DateTime, in the most unexpected way. Applications that want/need that will have to use DateTime throughout. 4. As I have said, the only other implicit time I would consider slightly viable is noon, but as far as least surprise, sort order behavior, etc goes, using the start of the day is imho the singular choice. 5. (Using 00:00:00.000 also follows the time honored IT convention of "filling things up with zeroes", if not explicitly told differently ;-) ) Cheers, mg *Otherwise a point in time could be in more than one interval (e.g. belong to more than one day). On 18/11/2021 14:22, Jochen Theodorou wrote: On 17.11.21 20:28, MG wrote: [...] 3. I have never encountered any other assumption than the one that a Date carries the implicit time of midnight (00:00:00.000...). What other time would one logically pick, given that time intervals are by convention typically closed on the left and open on the right ? But you have here already trouble. you can take the start of the day, or the end of the day. both is midnight, both based on the same date, but they are basically 24h apart. In my last project we mostly used end of the day for example. And in some parts actually 2:00 in the morning, because it is the time to run after some processes... which did not proof to be a good idea btw. bye Jochen 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.
