为什么该值设置为落后1小时？
如果
Europe/DublinEurope/LondonJVM: Europe/Dublin - TimeZone.getDefault().getID() or
JVM: Europe/London - TimeZone.getDefault().getID()
// LocalTime.ofInstant(now, Clock.systemDefaultZone().getZone())
01:32:13.283256
目前与UTC相同，没有偏移。
使用配置属性为 Spring / Hibernate 设置 JDBC 连接的时区：
spring.jpa.properties.hibernate.jdbc.time_zone=UTC
数据库查询：
select * from item;
id | local_time
----+------------
1 | 00:32:13
local_timetime这反映了 1970 年都柏林全年都是 UTC+1 的事实。
来自TZ数据库中的欧洲文件：
# From Paul Eggert (2018-02-15):
# In January 2018 we discovered that the negative SAVE values in the
# Eire rules cause problems with tests for ICU:
# https://mm.icann.org/pipermail/tz/2018-January/025825.html
# and with tests for OpenJDK:
# https://mm.icann.org/pipermail/tz/2018-January/025822.html
#
# To work around this problem, the build procedure can translate the
# following data into two forms, one with negative SAVE values and the
# other form with a traditional approximation for Irish timestamps
# after 1971-10-31 02:00 UTC; although this approximation has tm_isdst
# flags that are reversed, its UTC offsets are correct and this often
# suffices. This source file currently uses only nonnegative SAVE
# values, but this is intended to change and downstream code should
# not rely on it.
#
# The following is like GB-Eire and EU, except with standard time in
# summer and negative daylight saving time in winter. It is for when
# negative SAVE values are used.
# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule Eire 1971 only - Oct 31 2:00u -1:00 -
Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 -
Rule Eire 1972 1980 - Oct Sun>=23 2:00u -1:00 -
Rule Eire 1981 max - Mar lastSun 1:00u 0 -
Rule Eire 1981 1989 - Oct Sun>=23 1:00u -1:00 -
Rule Eire 1990 1995 - Oct Sun>=22 1:00u -1:00 -
Rule Eire 1996 max - Oct lastSun 1:00u -1:00 -
# Zone NAME STDOFF RULES FORMAT [UNTIL]
#STDOFF -0:25:21.1
Zone Europe/Dublin -0:25:21 - LMT 1880 Aug 2
-0:25:21 - DMT 1916 May 21 2:00s
-0:25:21 1:00 IST 1916 Oct 1 2:00s
0:00 GB-Eire %s 1921 Dec 6 # independence
0:00 GB-Eire GMT/IST 1940 Feb 25 2:00s
0:00 1:00 IST 1946 Oct 6 2:00s
0:00 - GMT 1947 Mar 16 2:00s
0:00 1:00 IST 1947 Nov 2 2:00s
0:00 - GMT 1948 Apr 18 2:00s
0:00 GB-Eire GMT/IST 1968 Oct 27
# Vanguard section, for zic and other parsers that support negative DST.
1:00 Eire IST/GMT
# Rearguard section, for parsers lacking negative DST; see ziguard.awk.
# 1:00 - IST 1971 Oct 31 2:00u
# 0:00 GB-Eire GMT/IST 1996
# 0:00 EU GMT/IST
# End of rearguard section.
伦敦也有同样的问题：
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone Europe/London -0:01:15 - LMT 1847 Dec 1
0:00 GB-Eire %s 1968 Oct 27
1:00 - BST 1971 Oct 31 2:00u
0:00 GB-Eire %s 1996
0:00 EU GMT/BST
# From Paul Eggert (2018-02-15):
# In January 2018 we discovered that the negative SAVE values in the
# Eire rules cause problems with tests for ICU:
# https://mm.icann.org/pipermail/tz/2018-January/025825.html
# and with tests for OpenJDK:
# https://mm.icann.org/pipermail/tz/2018-January/025822.html
#
# To work around this problem, the build procedure can translate the
# following data into two forms, one with negative SAVE values and the
# other form with a traditional approximation for Irish timestamps
# after 1971-10-31 02:00 UTC; although this approximation has tm_isdst
# flags that are reversed, its UTC offsets are correct and this often
# suffices. This source file currently uses only nonnegative SAVE
# values, but this is intended to change and downstream code should
# not rely on it.
#
# The following is like GB-Eire and EU, except with standard time in
# summer and negative daylight saving time in winter. It is for when
# negative SAVE values are used.
# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule Eire 1971 only - Oct 31 2:00u -1:00 -
Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 -
Rule Eire 1972 1980 - Oct Sun>=23 2:00u -1:00 -
Rule Eire 1981 max - Mar lastSun 1:00u 0 -
Rule Eire 1981 1989 - Oct Sun>=23 1:00u -1:00 -
Rule Eire 1990 1995 - Oct Sun>=22 1:00u -1:00 -
Rule Eire 1996 max - Oct lastSun 1:00u -1:00 -
您有解决这个问题的方法吗？导致读取数据库值时会假设错误的 local_time 值（关闭 1 小时）？