Bug 64226

We have an existing web application deployed within Tomcat. Recently we upgraded Tomcat from 8.0.32 to 9.0.27. The application sets an Expires HTTP header ultimately via Response.setDateHeader. Initially the application correctly returns the Expires header in the GMT timezone but over time (since the last restart) these headers begin to be returned in CET timezone. Different nodes in the cluster will flip to CET at different times.

We can flip a node to CET by sending a request with a CET date in a header e.g.
$ curl -H "If-Modified-Since: Thu, 12 Mar 2020 14:40:22 CET" --verbose localhost:18000/some/url/within/our/application -o /dev/null

After investigation the issue appears to be with the new ConcurrentDateFormat class which uses a ConcurrentLinkedQueue to hold a reusable collection of SimpleDateFormats. The collection is shared between the format and parse methods. When parse is called with a date string containing a timezone that is *not* GMT (e.g. "Thu, 12 Mar 2020 14:40:22 CET") then the timezone within the SimpleDateFormat used is changed to the timezone in the string (e.g. CET). This SimpleDateFormat is then placed back in the queue where it will be used by calls to format which will then return date strings in the wrong timezone.