Unfortunately I haven't been able to diagnose what is causing this, but basically... if you have a page with a <fmt> tag, it works fine, and if you do a <c:import> to that page locally, the results come across fine. However, if you use <c:import> to make a remote call to that page, the <fmt> tag ignores both pattern and type attributes, and just looks like it prints the Date.toString(). I'll attach test1.jsp and test2.jsp that demonstrate this behavior for me. This was tested with 1.0.3 (version not available in bugzilla).
Created attachment 5170 [details] Simple use of fmt:formatDate tag
Created attachment 5171 [details] Using c:import remotely on test1.jsp causes problems
One more note... if you specify javax.servlet.jsp.jstl.fmt.fallbackLocale in web.xml, then the pattern and type attributes are no longer ignored and it behaves as one would expect.
Serge, As specified in section 7.4 of the spec (under 'Absolute URL'), When using an absolute URL to import a resource, none of the current execution environment (e.g. request and session attributes) is made available to the target resource, even if that absolute URL resolves to the same host and context path. Therefore, the request parameters of the importing page are not propagated to the target absolute URL. This explains why the locale used by the formatting tags won't necessarily be the same when importing a resource with an absolute URL. -- Pierre
Pierre, I see how this bug could be determined as invalid. To me though, since the first page request is having a locale set by the information in the browser's request, I would expect the c:import to carry the necessary information for that same locale detection. As you can see from the test JSPs, I am not depending on request or session attributes. I believe what would need to happen is passing the appropriate header(s) through to have locale detection in the imported page. I understand this is part of execution context that's not supposed to be passed, but this is generally something a developer has any control over. Also, I don't see an easy way to pass this locale information to the imported page.
Serge, I've added this issue to the TODO list for JSTL.next. Hopefully, you'll join the new JSR to help us resolve the issue appropriately :-) [A workaround is to use a relative URL, but I understand this might not be possible in your specific situation...]