3 ms·
Good article, but “Java deprecated their Date way back in 1997” is not exactly true. They deprecated a lot of methods and constructors in JDK1.1 when Calendar w
by rjrjrjrj 9mo ago
Good article, but “Java deprecated their Date way back in 1997” is not exactly true. They deprecated a lot of methods and constructors in JDK1.1 when Calendar was introduced, but the class itself was never deprecated and it was the preferred way to represent a point in time until the “modern” approach was provided in java.time in JDK8 (c2014)
- shellac 9mo agoNot exactly true, but they deprecated absolutely everything that made it a date. It expresses deep regret in the medium of annotations: https://javaalmanac.io/jdk/1.2/api/java/util/Date.html https://javaalmanac.io/jdk/1.2/api/java/util/Date.html (I can't find the 1.1 docs, but they were the same) It's one of my favourite examples of how languages pretty much always get date and time hopelessly wrong initially. Java now has one of the best temporal APIs.
- KwanEsq 9mo agohttps://javaalmanac.io/jdk/1.1/api/java.util.Date.html https://javaalmanac.io/jdk/1.1/api/java.util.Date.html
- shellac 9mo agoCurses, I was close. Also: yikes to the design.
- rjrjrjrj 9mo agoYeah, it effectively became a typed wrapper of a long epoch millis value. Generally treated as immutable by convention in my experience, although of course it technically wasn't as the setters were never removed. It was hopelessly wrong initially, and got even worse when they added the horrible sql Date/Timestamp/etc classes. With java.time though, it is the gold standard as far as I've seen.
- cogman10 9mo agoJava's time and duration representations, heavily based on Joda, should be the standard that every language works towards. It's just about perfect in every way. It makes it easy to do the right thing and it's very pleasant to read.