SimpleDateFormat can be extremely slow to parse about httpresponsecache HOT 9 CLOSED

Locale.getDefault() may return any locale - and any formatting rules. For example, it may even return a locale which does not use the Gregorian calendar. HTTP dates are expected to be in a specific format, and as far as I know, using Locale.US is the way to do that.

from httpresponsecache.

Which device+OS are you using? I believe that in ICS (and earlier?) the US and default locales are always preloaded and available immediately.

from httpresponsecache.

I was testing in the gingerbread emulator. It did show that line in each time you instance SimpleDateFormat.

from httpresponsecache.

I can confirm. Tested on 2.3.5 on the HTC Rom, in log is

04-08 12:26:09.980: I/global(19394): Loaded time zone names for en_US in 987ms.

But on ICS it is OK

from httpresponsecache.

What about simply cache whole instance of SimpleDateFormat("formatString", Locale.US) as static variable?

from httpresponsecache.

SimpleDateFormat is not thread safe, see http://docs.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html
So we can't have one global instance.

from httpresponsecache.

And it's problem synchronize it? I don't think that it will be bottleneck, it is only very small time compared by whole network communication. But if you don't think it, another way is use ThreadLocal.

from httpresponsecache.

Could potentially store one instance of SimpleDateFormat (with US locale) then use ".clone()" to get a copy each time a thread needs to use it. Not sure whether concurrent use of two instances cloned from the same original instance would be thread-safe. If so, though, it gets around the locale lookup problem.

from httpresponsecache.

Please see issue #19

from httpresponsecache.