What Java data type will Date of Birth be?

Question

I am currently making an App on Android where a user will Register their details.

In my database I have DOB as a Date type.

Would I declare DOB in Java as a String? Double? Int? I'm confused how I will go about this so it satisfies the database's Date format.

Any help will be great!

Solution

A java.time.LocalDate (or logically-equivalent classes likes org.joda.time.LocalDate) is the best way to represent a date-of-birth (DOB) in Java code.

Note that DOB is not well-modelled as a java.sql.Date, or a java.util.Date: these model instants in time, not timezone-independent dates.

Whilst one is clearly born at some instant in time, this is not how we, societally, report when we are born. Consider that two children born at the same instant in different time zones might actually have different dates of birth - if the child in NYC is born at 2AM on 1st April, the child born in LA is born at 10PM on 31st March.

Neither child's date of birth changes when they travel to the other city (or anywhere else, of course). As such, if you store the instant of birth, you also need to store the time zone of birth in order to correctly interpret that instant as the date of birth.

But storing an instant and a timezone is inconvenient: not only is it more data to store, but also it is difficult to interpret it "by eye" (e.g. it's hard to tell what date (1459438541000, America/Los_Angeles) refers to). It is much easier to store and interpret the year, month and day directly: (2016, 3, 31).

Comments

[Admin]

So once I import java.time.LocalDate, how do I implement it so that a User using the app can enter their data of birth if I've declared DOB as int dob, how can I make (2016, 3, 31) acceptable as an int?

[Andy Turner]

Well, I'm advising that you store it as a LocalDate, not an int. But if you have to store it as an int (which gets back to the problem of "what does date 1459438541000" mean above), you can store it as the number of days after a given datum, e.g. a Julian date.

[Andy Turner]

* I'm advising that you represent it in your Java code as a LocalDate. You can persist it however it is convenient.

[Basil Bourque]

@AndyTurner Excellent Answer is except for one problem: java.sql.Date does indeed pretend to be a date-only value along the lines of java.time.LocalDate. java.sql.Date inherits (awkwardly) from java.util.Date. So it does indeed contain the time-of-day but sets that to 00:00:00.0 in a poorly designed attempt to fake being a local date rather than an instant-in-time as you indicated. We do use java.sql.Date as the class for moving java.time.LocalDate values in/out of the database, until our JDBC drivers are updated to handle java.time types directly.

[Andy Turner]

@BasilBourque Yes, it pretends to be that, but it doesn't change the fundamental representation as an instant. It is a lot more error-prone than using LocalDate - for instance, the output of System.out.println(new SimpleDateFormat("yyyy/MM/dd").format(new java.sql.Date(0))) depends upon JVM configuration. I'm not saying it's not possible to use it, just it requires a lot more care than LocalDate.

[Basil Bourque]

@AndyTurner Okay, agreed.