Are TimeZone instances guaranteed to be thread-safe
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.
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
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.
More information about the core-libs-dev