Вашият клиент getDate() кодът изглежда правилен, доколкото е възможно. Мисля, че също трябва да получите MySQL Connector/J JDBC драйвер, за да третирате датите, съхранени в таблицата като UTC дати, за да се избегне фалшиво преобразуване на часовата зона. Това означава задаване на ефективната часова зона на сървъра, в допълнение към часовата зона на клиентската сесия и календара, използвани за JDBC getTimestamp се обажда, както правите.
Разгледайте стойностите, които сте получили в неуспешното си твърдение, и в каква посока е грешката:
expected:<Thu Apr 16 11:30:30 BST 2015> but was:<Thu Apr 16 10:30:30 BST 2015>
Това, което получихте, беше 10:30 BST, което е 9:30 GMT. Това е в съответствие с базата данни, която третира това 10:30 в таблицата като BST стойност и фалшиво го преобразува в GMT вместо вас, преди да го анализирате като GMT дата. Това е обратната посока на фалшиво преобразуване на GMT стойност в BST.
Това може да е проблем, специфичен за JDBC, тъй като JDBC изисква времената да се преобразуват в локалната зона. (Където MySQL C API не го прави, вероятно защото класическите типове време на C не са наясно със зоната, както Java.) И трябва да знае от коя зона от преобразува , също така. MySQL TIMESTAMP типът винаги се съхранява като UTC. Но това не е посочено за DATETIME Тип. Мисля това означава, че MySQL ще интерпретира DATETIME стойностите на колоните са в часовата зона на сървъра. Което споменахте като зададено на BST и това е в съответствие с посоката на изместване, показана в съобщението за грешка при вашето твърдение.
time_zone Променливата на сесията, която задавате, казва на MySQL сървъра каква е часовата зона на вашата клиентска машина, но не влияе на това, което сървърът смята, че е неговата собствена часова зона. Това може да бъде отменено с serverTimezone Свойство на JDBC връзка
. Във вашата връзка задайте serverTimezone до UTC и се уверете, че useLegacyDatetimeCode е изключен. (И прегледайте другите свойства, свързани със зоната, ако това не работи.) Вижте дали датите ви ще се представят като UTC със същите стойности на полетата на календара като в базата данни.
Имайте предвид, че това ще промени интерпретацията на други DATETIME стойности във вашата база данни:всички те ще изглеждат като UTC дати сега (в контекста на вашата JDBC връзка). Дали това е правилно ще зависи от това как са били заселени първоначално. Въпреки че вашият клиентски код ще има поведението, което искате, не знам дали тази система като цяло може да се накара да се държи напълно последователно, без да се задава часовата зона на сървъра на UTC на ниво сървър. По принцип, ако зоната му не е зададена на UTC, тя не е напълно конфигурирана за поведението, което искате, и вие се бъркате около него.
