How Badly Do We Want a New Java Date/Time API? | Hacker News Reader

How Badly Do We Want a New Java Date/Time API?

java.dzone.com

37 pointsfriendlytuna10 comments

I've given up on the native Date/Time stuff in favour for Joda Time (http://joda-time.sourceforge.net/)

Joda Time is an absolute necessity for working reliably with dates and times, especially if you're handling different timezones

I know nothing about Joda Time (though I am pretty familiar with calendrics and am the author of YetAnotherToyGregorianCalendar routine). But I have to argue with the premise of your statement:

You cannot work reliably with dates and times, period. Even using the right software doesn't save you from a representation that sucks. Every spring in most places there are time values that don't exist. Every fall there are time values that are ambiguous and happen twice. Every year a bunch of governments change their time zone definitions and muck up a bunch of stored "future" times.

Do your work with "time" as a numeric quantity on a number line and convert to (never from) human-readable dates on output. If you need to parse a date, ever, you are doommed.

Apropos: http://blogs.msdn.com/b/windowsazure/archive/2012/03/09/summ...

Same - we've got a lot of legacy crap at my job and I haven't yet sold folks on Joda Time, but it's part of my standard jar set (Guava, Guice, Trove, Joda Time) for new personal projects.

Yes. The problem is that at some point you talk to some library function that uses java.util.Date, and there goes your time zone information (although with hackery you can sometimes get the library to do the right thing).

DATE4J is a good alternative to the standard Java Date/Time lib or even Joda Time. (http://www.date4j.net/)

I'm pretty sure most Java developers moved to Joda Time long ago to solve this issue. It's pretty much standard.

Well, maybe not enterprise developers (like me) who rarely get to use "untrusted" third party libs.

A long time ago (2010), I was told that we couldn't use generics or annotations because they weren't "industry standard Java." I suppose the reality of that phrase depends heavily on the industry.

http://blog.joda.org/search?q=jsr-310 provides some interesting backstory to the JSR-310 / Joda Time saga...

Reply on news.ycombinator.com