4 ms·

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

• Torn 15y ago
  Joda Time is an absolute necessity for working reliably with dates and times, especially if you're handling different timezones
  • ajross 15y ago
    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.
    • ajross 15y ago
      Apropos: http://blogs.msdn.com/b/windowsazure/archive/2012/03/09/summary-of-windows-azure-service-disruption-on-feb-29th-2012.aspx http://blogs.msdn.com/b/windowsazure/archive/2012/03/09/summ...
• eropple 15y ago
  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.
• hughw 15y ago
  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).