Что такое настройки драйвера JDBC-mysql для правильной обработки DATETIME и TIMESTAMP в UTC?

Ответ 1

Решение состоит в том, чтобы установить параметр соединения JDBC noDatetimeStringSync=true с useLegacyDatetimeCode=false. В качестве бонуса я также обнаружил, что sessionVariables=time_zone='-00:00' явно скрывает необходимость set time_zone в каждом новом соединении.

Существует некоторый "интеллектуальный" код преобразования часового пояса, который активируется глубоко внутри метода ResultSet.getString(), когда он обнаруживает, что столбец является столбцом TIMESTAMP.

Увы, этот интеллектуальный код имеет ошибку: TimeUtil.fastTimestampCreate(TimeZone tz, int year, int month, int day, int hour, int minute, int seconds, int secondsPart) возвращает TIMESTAMP неправильно помеченную в часовой пояс JVM по умолчанию, даже если параметр tz установлен на что-то еще:

final static Timestamp fastTimestampCreate(TimeZone tz, int year, int month, int day, int hour, int minute, int seconds, int secondsPart) {
    Calendar cal = (tz == null) ? new GregorianCalendar() : new GregorianCalendar(tz);
    cal.clear();

    // why-oh-why is this different than java.util.date, in the year part, but it still keeps the silly '0' for the start month????
    cal.set(year, month - 1, day, hour, minute, seconds);

    long tsAsMillis = cal.getTimeInMillis();

    Timestamp ts = new Timestamp(tsAsMillis);
    ts.setNanos(secondsPart);

    return ts;
}

Возврат ts будет абсолютно корректным, если только он не будет продолжен в цепочке вызовов, он будет преобразован обратно в строку с использованием метода bare toString(), который отображает ts как строку, представляющую, что такое часы отображается в часовом поясе JVM-default, вместо строкового представления времени в UTC. В ResultSetImpl.getStringInternal(int columnIndex, boolean checkDateTypes):

                case Types.TIMESTAMP:
                    Timestamp ts = getTimestampFromString(columnIndex, null, stringVal, this.getDefaultTimeZone(), false);

                    if (ts == null) {
                        this.wasNullFlag = true;

                        return null;
                    }

                    this.wasNullFlag = false;

                    return ts.toString();

Настройка noDatetimeStringSync=true отключает весь беспорядок разбора/разбора и просто возвращает строковое значение as-получено из базы данных.

Тестируемый выход:

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

Значение useLegacyDatetimeCode=false по-прежнему важно, поскольку оно изменяет поведение getDefaultTimeZone() для использования сервера базы данных TZ.

Во время преследования этого я также обнаружил, что документация для useJDBCCompliantTimezoneShift неверна, хотя она не имеет значения: документация говорит [Это часть устаревшего кода даты и времени, поэтому свойство имеет эффект только тогда, когда "useLegacyDatetimeCode = true." ], но это неправильно, см. ResultSetImpl.getNativeTimestampViaParseConversion(int, Calendar, TimeZone, boolean).