Simple Features Thoughts about simple features in software development

27Nov/102

Java Dates – Is long a good idea for handling dates?

Answer goes: yes, most of the times, but...

Definitively I won't just leave you there. Here is a small list of when to use it:

  • When you need to know the order of events
  • When you don't want to know the time in actually happened in your timezone
  • You are using System.currentTimeInMillis() as the time source

When you use System.currentTimeInMillis(), you are having an exact reference of a time, specifically 1970-01-01 00:00:00.000+0GMT. This way you always know your reference. Suppose you have a process running in México (-6GMT) and another one running on Hong Kong (+8GMT). Suppose both processes have an event at the precise same time, being 2010-11-27 06:44:21.113 in México and 2010-11-27 20:44:21.113 in Hong Kong.

Location Local date time System.currentTimeInMillis()
Mexico 2010-11-27 06:44:21.113 1290861861113
Hong Kong 2010-11-27 20:44:21.113 1290861861113
London 2010-11-27 00:44:21.113 1290861861113

One clear thing to look at: no matter where did you apply the System.currentTimeInMillis() the result were the same for any place, because actually, the result you've got was that one for London. If any other event would have happened one millisecond after in Mali, we can know that the sequence of the event was right after the events in Hong Kong and Mexico... simple.

Now.. Is long a good idea for storing dates?

The answer is: barely ever.

Having only the long date, it is quite improbable that you can know the time and date in local time when it happened. Even if you are not working on different timezones if you work with daylight savings time you will have to solve this issue.

EDIT: After a comment from Danny I realized I said that you can't know the local time and date. Yes, you can: any Date or Calendar object will realize how to read it. What you can't know is the timezone where it happened by only having the long date.

If you want to store dates, I recommend to use the ISO8601 format, and only when you will also make date and time ordering from the database, you can ALSO store the long format. Remember that disk space and not CPU cycles is cheap. Missing data is not expensive but invaluable.

And a final advice: NEVER, i mean, NEVER use the java.util.Calendar or java.util.Date classes. If in your hands use joda-time, otherwise leave the project or get ready to fail (reasons here).

Comments (2) Trackbacks (0)
  1. I was with you until your “is long a good idea for storing dates” section. Specifically, “Having only the long date, it is quite improbable that you can know the time and date in local time when it happened”. What? That’s completely counter to your first point which is that it gives you a snapshot in time regardless of location. If you need to know the local time a long-stored date happened, you populate an appropriate date/time object with the local timezone. What’s the problem?

    As for your final advice where you emphatically say to NEVER use Calendar or Date or “leave the proejct or get ready to fail”. That’s just ridiculous. java.util.Calendar is cumbersome, but it’s not broken. You’re not “going to fail” for using the standard date/time libraries w/ the JDK. Read the javadocs, use it right, there’s no problem.

    • About your first point… yes, I realize it now that you are saying it… and thank you.
      About the second point, I have worked for a long time with dates and it doesn’t JUST work. It works pretty awkward and you can always be sure there i’ll be a new behavior that will take you to testing for a couple more hours before you can keep on coding. Now, my point of “leave the project or get ready to fail” it’s nothing but an exageration of the facts, I mean, a huge warning sign for other developers. I have worked for years without using joda or any other library but the JDK and everything went ok at the end, but after long hours of extra-testing.
      Thanks for the comments


Leave a comment

Trackbacks are disabled.