java.sql. Конкретный часовой пояс метки времени?

Question

java.sql. Конкретный часовой пояс метки времени?

I have to store UTC dateTime in DB.
I have converted the dateTime given in specific timezone to UTC. for that I followed the below code.
My input dateTime is "20121225 10:00:00 Z" timezone is "Asia/Calcutta"
My Server/DB(oracle) is running in the same timezone(IST) "Asia/Calcutta"

Получают объект Даты в этом определенном Часовом поясе

        String date = "20121225 10:00:00 Z";
        String timeZoneId = "Asia/Calcutta";
        TimeZone timeZone = TimeZone.getTimeZone(timeZoneId);

        DateFormat dateFormatLocal = new SimpleDateFormat("yyyyMMdd HH:mm:ss z");
                    //This date object is given time and given timezone
        java.util.Date parsedDate = dateFormatLocal.parse(date + " "  
                         + timeZone.getDisplayName(false, TimeZone.SHORT));

        if (timeZone.inDaylightTime(parsedDate)) {
           //We need to re-parse because we don't know if the date
           //is DST until it is parsed...
            parsedDate = dateFormatLocal.parse(date + " "
                    + timeZone.getDisplayName(true, TimeZone.SHORT));
        }

       //assigning to the java.sql.TimeStamp instace variable
        obj.setTsSchedStartTime(new java.sql.Timestamp(parsedDate.getTime()));

Магазин в DB

        if (tsSchedStartTime != null) {
            stmt.setTimestamp(11, tsSchedStartTime);
        } else {
            stmt.setNull(11, java.sql.Types.DATE);
        }

ПРОДУКЦИЯ

DB (оракул) сохранила, те же самые данные дату и время: "20121225 10:00:00 не в UTC.

Я подтвердил от ниже sql.

     select to_char(sched_start_time, 'yyyy/mm/dd hh24:mi:ss') from myTable

Мой сервер БД, также работающий на том же самом часовом поясе "Азия/Калькутта"

Это дает мне ниже появлений

Date.getTime() is not in UTC
Or Timestamp is has timezone impact while storing into DB What am I doing wrong here?

Еще один вопрос:

<Закодирует> timeStamp.toString() , печать в местном часовом поясе как java.util.date делает? Не UTC?

63

добавлено 28 Декабрь 2012 в 01:53 автор Kanagavelu Sugumar отредактировано 30 Июнь 2015 в 02:59

Просмотры: 3

источник

nl ja de

@Kanagavelu Sugumar: Да. getTime метод класса Даты возвращает количество миллисекунд с 1 января 1970, 0:00:00 GMT.

добавлено 28 Декабрь 2012 в 02:50, автор Gilbert Le Blanc, источник

Отвечать на вопрос в вашем титуле, нет, java.sql. Метка времени основана на UTC. Показ метки времени является конкретным часовым поясом.

добавлено 28 Декабрь 2012 в 02:06, автор Gilbert Le Blanc, источник

@GilbertLeBlanc, Хотя java.sql. Метка времени находится в UTC, храня в области МЕТКИ ВРЕМЕНИ без информации о часовом поясе, это использует эквивалентную дату/время в текущем часовом поясе виртуальной машины

добавлено 28 Декабрь 2012 в 02:25, автор Mark Rotteveel, источник

@MarkRotteveel отмечают I didn' t понимают вашу мысль, "хранящую в области МЕТКИ ВРЕМЕНИ без информации о часовом поясе, она использует эквивалентную дату/время в текущем часовом поясе виртуальной машины". Не могли бы Вы уточнить в своем ответе. Это будет более полезно мне.

добавлено 28 Декабрь 2012 в 06:42, автор Kanagavelu Sugumar, источник

@Gilbert Леблан Спасибо!. Не могли бы Вы ответить мне "новый java.sql. Метка времени (parsedDate.getTime ())" возвратит объект метки времени GMT для моего входа?

добавлено 28 Декабрь 2012 в 02:23, автор Kanagavelu Sugumar, источник

4 ответы

Видеокурс по Java для начинающих

Получи видеокурс по Java для начинающих с упражнениями

Хотя это явно не определяется для setTimestamp (интервал parameterIndex, Метка времени x) , водители должны следовать правилам, установленным setTimestamp(int parameterIndex, Timestamp x, Calendar cal) javadoc:

Устанавливает обозначенный параметр на даваемый <кодовый> java.sql. Метка времени стоимость, используя данный Календарь объект. Водитель использует , Календарь возражает, чтобы построить SQL МЕТКА ВРЕМЕНИ стоимость, которую водитель тогда посылает в базу данных. С Календарь объект, водитель может вычислить метку времени, принимающую во внимание таможенный часовой пояс. Если никакой Календарь объект определяется, водитель использует часовой пояс по умолчанию, который является часовым поясом виртуальной машины, запускающей приложение.

Когда вы звоните с setTimestamp (интервал parameterIndex, Метка времени x) , водитель JDBC использует часовой пояс виртуальной машины, чтобы вычислить дату и время метки времени в том часовом поясе. Эта дата и время - то, что сохранено в базе данных, и если колонка базы данных не хранит информацию часового пояса, то любая информация о зоне потеряна (что означает, что это до применения (применений), используя базу данных, чтобы последовательно использовать тот же самый часовой пояс или придумать другую схему различить часовой пояс (т.е. магазин в отдельной колонке).

Например: Ваша зона местного времени - GMT+2. Вы храните "2012-12-25 10:00:00 UTC". Фактическое значение, сохраненное в базе данных, "2012-12-25 12:00:00". Вы восстанавливаете его снова: вы возвращаете его снова как "2012-12-25 10:00:00 UTC" (но только если вы восстанавливаете, это, используя getTimestamp (..) ), но когда другой доступы к приложениям база данных в часовом поясе GMT+0, это восстановит метку времени как "2012-12-25 12:00:00 UTC".

Если вы хотите сохранить его в различном часовом поясе, то необходимо использовать setTimestamp (интервал parameterIndex, Метка времени x, Календарь cal) с Календарным случаем в необходимом часовом поясе. Просто удостоверьтесь, что вы также используете эквивалентного получателя с тем же самым часовым поясом, восстанавливая ценности (если вы используете МЕТКУ ВРЕМЕНИ без информации о часовом поясе в вашей базе данных).

Так, принятие вас хочет сохранить фактический часовой пояс GMT, необходимо использовать:

Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
stmt.setTimestamp(11, tsSchedStartTime, cal);

С JDBC 4.2 послушный водитель должен поддержать java.time. LocalDateTime (и java.time. LocalTime ) для МЕТКА ВРЕМЕНИ (и ВРЕМЯ ) через get/set/updateObject . java.time. Местный* классы без часовых поясов, таким образом, никакое преобразование не должно быть применено (хотя это могло бы открыть новый набор проблем, если бы ваш код действительно принимал определенный часовой пояс).

90

добавлено 28 Декабрь 2012 в 02:11 автор Mark Rotteveel

источник

@KanagaveluSugumar видят мое обновление

добавлено 28 Декабрь 2012 в 02:24, автор Mark Rotteveel, источник

toString() на java.lang. Дата (и java.lang. Метка времени ), будет всегда представлять его в вашем местном часовом поясе.

добавлено 29 Декабрь 2012 в 09:35, автор Mark Rotteveel, источник

@KanagaveluSugumar, Который является фактической стоимостью метки времени, чтобы установить. Водитель только использует Календарный объект для получения информации о часовом поясе, не для ее стоимости!

добавлено 28 Декабрь 2012 в 02:27, автор Mark Rotteveel, источник

Я хочу сохранить свое время в GMT. Я верю своей метке времени в GMT. Таким образом, что я должен сделать? это - setTimestamp (интервал parameterIndex, Метка времени tzGmtObj, Календарь calGmtObj)??

добавлено 28 Декабрь 2012 в 02:19, автор Kanagavelu Sugumar, источник

если "setTimestamp (интервал parameterIndex, Метка времени x)" использует часовой пояс виртуальной машины. какова роль x в коде?

добавлено 28 Декабрь 2012 в 02:26, автор Kanagavelu Sugumar, источник

ох Большой!!! Я попробую это в своем коде. и сообщите результат. Большое спасибо.

добавлено 28 Декабрь 2012 в 02:32, автор Kanagavelu Sugumar, источник

Большой, Это работает:) Я трачу партию времени, чтобы доказать (Дата/Метка времени) .getTime() считает часовой пояс определенным временем в миллисекундах. Теперь я понял, что Это не. Это всегда дает миллисекунды UTC независимо от часового пояса. Но (Дата/Метка времени) .toString() является конкретным часовым поясом. Большое спасибо.

добавлено 28 Декабрь 2012 в 06:34, автор Kanagavelu Sugumar, источник

Спасибо. Это спасло мой зад в попытке выяснить, почему то, что хранилось в базе данных, не было тем, что передавалось к нему.

добавлено 21 Май 2014 в 07:50, автор Trebor, источник

Видеокурс "Создание приложений для Android"

Получи множество видеоуроков по Android сейчас

Система управления ссылками ReDirector 3.0

Автор: Евгений Попов

Мини-курс по Angular и NgRx

16 видео-уроков

автор Evgeniy Dorofeev · Answer 1 · 2012-12-28T02:42Z

Я думаю, что правильный ответ должен быть java.sql. Метка времени не конкретный часовой пояс. Метка времени - соединение java.util. Дата и отдельная стоимость наносекунд. В этом классе нет никакой информации о часовом поясе. Таким образом, как Датируются, этот класс просто держит количество миллисекунд с 1 января 1970, 0:00:00 GMT + nanos.

В PreparedStatement.setTimestamp (интервал parameterIndex, Метка времени x, Календарь cal) Календарь используется водителем, чтобы изменить часовой пояс по умолчанию. Но Метка времени все еще держит миллисекунды в GMT.

API неясен о том, как точно водитель JDBC, как предполагается, использует Календарь. Поставщики, кажется, не стесняются о том, как интерпретировать его, например, в прошлый раз, когда я работал с календарем MySQL 5.5, водитель просто проигнорировал Календарь и в PreparedStatement.setTimestamp и в ResultSet.getTimestamp.

автор Woot4Moo · Answer 2 · 2012-12-28T02:01Z

Это конкретно от вашего водителя. Необходимо поставлять параметр в Явской программе, чтобы сказать ему часовой пояс, который вы хотите использовать.

java -Duser.timezone="America/New_York" GetCurrentDateTimeZone

Далее это:

to_char(new_time(sched_start_time, 'CURRENT_TIMEZONE', 'NEW_TIMEZONE'), 'MM/DD/YY HH:MI AM')

May also be of value in handling the conversion properly. Taken from here

автор Abdelhafid · Answer 3 · 2016-05-02T01:06Z

Для Mysql у нас есть ограничение. В доктор водителя Мискла, мы имеем:

Следующее - некоторые известные проблемы и ограничения для MySQL Connector/J: Когда Connector/J восстанавливает метки времени для дневного света экономить время (DST) переключает день, используя getTimeStamp() метод на набор результатов, некоторые возвращенные ценности могли бы быть неправильными. Ошибки могут избегайте при помощи следующих вариантов связи, соединяясь к базе данных:

useTimezone=true
useLegacyDatetimeCode=false
serverTimezone=UTC

Так, когда мы не используем это параметры, и мы звоним setTimestamp или getTimestamp с календарем или без календаря, у нас есть метка времени в jvm часовом поясе.

Пример:

The jvm timezone is GMT+2. In the database, we have a timestamp : 1461100256 = 19/04/16 21:10:56,000000000 GMT

Properties props = new Properties();
props.setProperty("user", "root");
props.setProperty("password", "");
props.setProperty("useTimezone", "true");
props.setProperty("useLegacyDatetimeCode", "false");
props.setProperty("serverTimezone", "UTC");
Connection con = DriverManager.getConnection(conString, props);
......
Calendar nowGMT = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
Calendar nowGMTPlus4 = Calendar.getInstance(TimeZone.getTimeZone("GMT+4"));
......
rs.getTimestamp("timestampColumn");//Oracle driver convert date to jvm timezone and Mysql convert date to GMT (specified in the parameter)
rs.getTimestamp("timestampColumn", nowGMT);//convert date to GMT 
rs.getTimestamp("timestampColumn", nowGMTPlus4);//convert date to GMT+4 timezone

The first method returns : 1461100256000 = 19/04/2016 - 21:10:56 GMT

The second method returns : 1461100256000 = 19/04/2016 - 21:10:56 GMT

The third method returns : 1461085856000 = 19/04/2016 - 17:10:56 GMT

Вместо Oracle, когда мы используем те же самые требования, мы имеем:

The first method returns : 1461093056000 = 19/04/2016 - 19:10:56 GMT

The second method returns : 1461100256000 = 19/04/2016 - 21:10:56 GMT

The third method returns : 1461085856000 = 19/04/2016 - 17:10:56 GMT

NB : It is not necessary to specify the parameters for Oracle.