Incorrect validation of DST in java.util.SimpleTimeZone

Seán Coffey sean.coffey at
Fri Nov 10 15:59:40 UTC 2017

I think the OpenJDK mailing lists accept attachments if in patch format. 
If it's a simple short patch, it's acceptable to paste it into email body.

Easiest solution is to use webrev[1]. If you can't upload this to - then one of your colleagues may be able to help.



On 10/11/17 12:18, Venkateswara R Chintala wrote:
> Looks like the patch attached earlier is not visible. As this is my 
> first contribution, please let me know how I can send the patch for 
> review.
> On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
>> Hi,
>> In a multi-threaded environment, when java.util.SimpleTimeZone object 
>> is used to create a default timezone, there can be a race condition 
>> between the methods java.util.Timezone.getDefault() and 
>> java.util.Timezone.getDefaultRef() which can result in inconsistency 
>> of cache that is used to validate a particular time/date in DST.
>> When a thread is cloning a default timezone object (SimpleTimeZone) 
>> and at the same time if a different thread modifies the time/year 
>> values, then the cache values (cacheYear, cacheStart, cacheEnd) can 
>> become inconsistent which leads to incorrect DST determination.
>> We considered two approaches to fix the issue.
>> 1)Synchronize access to cloning default timezone object when cache is 
>> being modified.
>> 2)Invalidate the cache while returning the clone.
>> We preferred the second option as synchronization is more expensive.
>> We have attached the patch and jtreg testcase. Please review.

More information about the core-libs-dev mailing list