Hacker News new | ask | show | jobs
by stygiansonic 3809 days ago
This is just an aside, and not a knock on the article, but Java does have a built-in Timestamp type, [1] and has had it for some time.

Maybe it's not "first-class" (not sure what this means in context?), but it's definitely there and not in a third-party JAR or anything.

However, it's bad for other reasons, the first being that it extends java.util.Date (the Javadoc seems to admit this) and combined with the related java.sql.Date (which also extends java.util.Date) makes for a very confusing API.

For this reason, Oracle recommends just using the new Date APIs, [2] and mapping a SQL TIMESTAMP to LocalDateTime.

1. https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp...

2. http://www.oracle.com/technetwork/articles/java/jf14-date-ti...

1 comments

The original Java date and time API was probably one of the worst APIs ever invented, as I describe in my answer on StackOverflow: http://stackoverflow.com/a/1969651

However the new javax.time APIs (created by Stephen Colebourne) are excellent and probably one of the best designed APIs. It's funny what twenty years difference can make :)

It's worth noting that much of the original java.util.Date class was based on the same misfeatures as POSIX C:

1. Leap seconds? Those don't exist, right? 2. Years date from 1900. 3. January is Month 0 (ignoring the fact that there is already a widespread convention of numbering January 1).

Of course, the "fix" of Calendar didn't attempt to fix any of the POSIX-did-it-first problems but instead mostly limited itself to supporting other locales by allowing non-Gregorian calendars.

Totally concur. But date/time is a hard thing to get right!

However, getting it wrong the first time is different than getting wrong again, as you pointed out with the Calendar type. 0 == JANUARY, but most other things are indexed from 1...

Third time's the charm, I guess :) Getting the input from Stephen Colebourne (of Joda-Time fame) was undoubtedly a key point in getting this done.

Numbering months from 0 is obnoxiously common in these time APIs. This is one of the few edge cases where IMHO we should index from 1, because people frequently just use the numeric version for output and it is way too easy to forget to add or subtract 1 from the month value. The memory lost by having an empty 0 spot in the month name array is absolutely not a concern in any sane project.