Home/ Questions/Q 378927
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T14:50:32+00:00

Which is the most beneficial in Java and a DB for DateTime? (Using JodaTime

  • 0

Which is the most beneficial in Java and a DB for DateTime? (Using JodaTime as Date)

(DateTime object (Java) + TIMESTAMP (DB) ) VS (Milliseconds long (Java) + BIGINT(DB)

for the use of DateTime information in Java Web application backed by an underlying Database

Areas of interest

  • manipulating, processing and memory usage in Java
  • saving using efficient storage space in
    a MySQL database
  • ease of porting a BIGINT/TIMESTAMP column to other DBs
  • ease of searching the DB for a BIGINT/TIMESTAMP or between two BIGINTs/TIMESTAMPs

E.g. Say I had an event with a start & end DateTime.
Is it faster to search for events on dates using BIGINT in the DB than TIMESTAMPS

I might be swapping the underlying DB as scalability and retrieval issues arise.

Would saving the DateTime as a TIMESTAMP in a MySQL DB lead problems when porting to another DB like Oracle?

I currently use the Joda DateTime in java then storing the millisecond of that value.

When retrieving it, I convert the milliseconds back to a DateTime object and display it.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There are really two questions here. First, what abstraction should you use in Java to represent time? Joda Time is definitely better than java.util.Date. If you are wondering whether to simply use a long — I imagine you can’t get away with that if you need to do any date manipulation or comparison. So, Joda Time.

    And then it is definitely best to use TIMESTAMP for this in MySQL as it will be nearly identical storage-wise and MySQL will treat the value appropriately, as a date, when you want to use date functions on the column. JDBC drivers will also understand that it should be mapped to a date type.

    I can’t imagine you will have trouble porting a date type, represented correctly as a date in your schema, to another database, should you need to. I can imagine problems if you treat the date type as a bigint, which is less correct.

    So, simply choose the most correct types here. I doubt there is any performance win available from choosing a less suitable type anyway.

    • 0