Are TimeZone instances guaranteed to be thread-safe

Bernd Eckenfels ecki at zusammenkunft.net
Sat Sep 1 01:58:19 UTC 2018


Ah BTW, there is a TimeZone.getTimezone(ZoneOffset.UTC) construct which can be used. The ZoneId is also immutable, but that construct does say nothing about TimeZone instance.

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: Bernd Eckenfels <ecki at zusammenkunft.net>
Gesendet: Samstag, September 1, 2018 3:22 AM
An: core-libs-dev at openjdk.java.net
Betreff: Are TimeZone instances guaranteed to be thread-safe

Hello,

I am not sure I missed it, but it looks like there is no definition in the JCL JavaDoc about instances of j.u.TimeZone (specifically SimpleTimeZone as well as instances obtained with getDefault or by Id) beeing reentrant/thread Safe or not. (There are for examplequite a few non-final fields in SimpleTimeZone as well),

Since TimeZone is used together with Calendar it might be natural for developers to know.

Is there a helper/factory which would allow access to some standard timezones (at least GMT/UTC). This might be especially useful if we cannot define TimeZone instances generally as thread safe, because then we can at least declare it for this „fast“ implementation.

[ Background of my question is BTW the rs.getTimestamp(idx, Calendar) method in the JDBC API where the need for constructing a Calendar object is painful and it would help if I could at least use new Calendar(SimpleTimeZone.UTC). (And having an alternative like getTimestamp(Int, ZoneId) would be even better ]

I can imagine naming it GMT vs. UTC might also be a nice bike shed.

Gruss
Bernd
--
http://bernd.eckenfels.net


More information about the core-libs-dev mailing list