The current caching mechanism used in DatePatternProvider is very fast and does not use ThreadLocals (which can cause memory leaks in web containers).
It does however allocate new objects every time the cached value cannot be reused and a new formatted timestamp needs to be created. These objects are: CachedTime, String (plus any objects needed to create this String).
It should be possible to create an alternative caching mechanism that does not allocate any objects when formatting a date.
This likely needs to be restricted to FixedDateFormat and perhaps the Unix times, since FastDateFormat creates a number of temp objects for each format invocation (GregorianCalendar, StringBuilder, String).
Another restriction is that, since this caching mechanism will likely involve ThreadLocals, it is not suitable for web applications.
I am thinking we may want some switch to determine which caching mechanism to use. This switch may be a general "GC-free" switch since there may be other places where behaviour differs depending on whether we want to be GC-free or not.