Breaking DateAndTime

[bodiam]

Hi all,

Another proposal: I'm thinking of breaking DateAndTime.

At the moment, it's using java.sql.Timestamp for future(), past() and birthday() methods. I don't think anyone would use a SQL Timestamp for these kind of things, and I'm thinking of changing it. I'm not sure how to deprecate them since I want to change the return type, but keep the method names and the provider it's in (I could make a new one and deprecate this one, but I'm not sure how to call it. TimeAndDate? DateAndTime2? I also plan on removing all references to java.util.Date.

The plan is to make birthday() return a LocalDate, and future and past I'm not sure of yet. Perhaps a ZonedDateTime, or an OffsetDateTime?

Suggestions welcome, if no objections, I will implement the above.

[kingthorin]

I agree that getting rid of java.sql.Timestamp usage is likely a good move. Is there a reason to move away from java.util.Date? (Not that I'm against it, I just want to understand the direction a bit better.)

Both ZonedDateTIme and OffSetDateTime support plus and minus methods so that seems like a simple way to handle future and past.

[bodiam]

I think java.util.Date is not something anyone should use with the introduction of java.time, and that's now more than 10 years ago! Also, Gavin King says you shouldn't: https://in.relation.to/2024/04/22/stop-using-date/

Also:

(source: https://stackoverflow.com/questions/32437550/whats-the-difference-between-instant-and-localdatetime/32443004#32443004)

So, possibly, we should be using Instant instead.

[kingthorin]

Thanks, great resources. Makes sense.

[asolntsev]

I guess this issue can be closed because it was implemented in #1210 ?