出现这个问题的原因是：Presto、Trino的驱动使用了joda这个库来处理时区的问题。但这个库的编写人似乎对java zone的格式没有太多经验。先看一下出错的代码：
com.facebook.presto.jdbc.internal.joda.time.DateTimeZone#forID
根据String类型的zoneId转成DateTimeZone。如果未设置使用默认的。如果设置了，则先判断是否是UTC的，是的话则直接使用UTC处理。然后使用Provider的getZone()方法获取。如果没有取到的话，根据zoneId是否是+，-开头，手动计算时区。这里的问题就在于，国内写代码时，大家一般都是这么写的：
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("GMT+8")));
会导致上面的所有判断没有命中，直接进入最后的异常抛出。
解决办法：
1、通过下面的语句可以避免异常。如果程序中能够兼容“+08:00”这种时区格式，可以直接在代码中设置。这种设置是全局性的，一旦调整，整个程序都有影响。如果有逻辑不兼容这种格式，那么这种方法是不通用的。
TimeZone.setDefault(TimeZone.getTimeZone("+08:00"));
或者：TimeZone.setDefault(TimeZone.getTimeZone("Asia/Shanghai"));
2、也可以试试不设置任何TimeZone，保持程序和环境默认。
3、最后还有一种，上面的代码中使用getProvider(), joda库本身只实现了两种，一个是UTC，顾名思义专门处理UTC时区；一个是ZoneInfoProvider，通过读取com.facebook.presto.jdbc.internal.joda.time/tz/data下的配置文件实现。看了一下里面是有shanghai的配置的。这个Provider是可以拓展的。我们可以增加一个自己的实现，来最小化数据库驱动对整个程序的影响。
示例代码：
DateTimeZone.setProvider(new Provider() {
@Override
public DateTimeZone getZone(String id) {
if (id.equals("UTC")) {
return DateTimeZone.UTC;
}
if (id.startsWith("GMT+08:00")) {
return DateTimeZone.forTimeZone(TimeZone.getTimeZone("+08:00"));
}
return null;
}
@Override
public Set<String> getAvailableIDs() {
return new TreeSet<String>() {
{
add("UTC");
add("GMT+8");
}
};
}
});
如果是Spring Boot程序，在main方法时调用即可。
?