4 ms·

If Java Date was so broken before this, what have businesses been using the past few years? The article mentioned Joda-Date, but I'm curious if companies have u

If Java Date was so broken before this, what have businesses been using the past few years? The article mentioned Joda-Date, but I'm curious if companies have used other solutions, or even built in-house solutions.

kasey_junk 13y ago
The joda libraries are the de-facto standard. I have seen custom solutions but usually those are for lower than millisecond resolution.
- greatsuccess 13y ago
  Actually it looks like Java 8 will improve on Joda-Time, its far from perfect.
smackfu 13y ago
A lot of people still use the built in Java stuff, they just don't enjoy it. Especially since a lot of code predates the existence of alternatives.
bhauer 13y ago
For most applications we build, if time is relevant for more than just incidental functionality, we will typically use Joda-Time. For simply incidental functionality (e.g., a few UI elements displaying the time), we'll use the standard API. I've not seen any home-brew date APIs outside of a few bite-size pieces of functionality. For instance, we have one custom utility that takes two times and a granularity level to render a human-readable rendering such as "2 hours, 13 minutes ago."
gcv 13y ago
The ICU Java libraries, though annoying to use, provide interoperability with ICU C libraries. ICU has the only correct implementation of time zone support for C that I have found. Though it's been a while since I researched the issue, I think ICU did something with time zones better than Joda Time, also.
rlmw 13y ago
Most people use the Jodatime library. JSR-310 is an extension of Stephen Colebourne's work on that library. Obviously there are some people who use java.util.Date, but it is a real pain in the neck to use and is very commonly complained about.
ajanuary 13y ago
We use a mix of the built-in java dates and joda, depending on how old the code is. We have our own time library for some domain specific time code, which internally uses joda to handle dates.

kasey_junk 13y ago

The joda libraries are the de-facto standard. I have seen custom solutions but usually those are for lower than millisecond resolution.

greatsuccess 13y ago
Actually it looks like Java 8 will improve on Joda-Time, its far from perfect.

smackfu 13y ago

A lot of people still use the built in Java stuff, they just don't enjoy it. Especially since a lot of code predates the existence of alternatives.

bhauer 13y ago

For most applications we build, if time is relevant for more than just incidental functionality, we will typically use Joda-Time. For simply incidental functionality (e.g., a few UI elements displaying the time), we'll use the standard API. I've not seen any home-brew date APIs outside of a few bite-size pieces of functionality. For instance, we have one custom utility that takes two times and a granularity level to render a human-readable rendering such as "2 hours, 13 minutes ago."

gcv 13y ago

The ICU Java libraries, though annoying to use, provide interoperability with ICU C libraries. ICU has the only correct implementation of time zone support for C that I have found. Though it's been a while since I researched the issue, I think ICU did something with time zones better than Joda Time, also.

rlmw 13y ago

Most people use the Jodatime library. JSR-310 is an extension of Stephen Colebourne's work on that library. Obviously there are some people who use java.util.Date, but it is a real pain in the neck to use and is very commonly complained about.

ajanuary 13y ago

We use a mix of the built-in java dates and joda, depending on how old the code is. We have our own time library for some domain specific time code, which internally uses joda to handle dates.