2010-08-02 12 views
2

Каков наилучший способ изменить часовой пояс приложения? То, как я вижу следующее должно произойти:grails/mysql изменение часового пояса

  1. TZ сервер изменен системным администратором
  2. MySQL должен быть перезапущен.
  3. каждый раз, когда базовый столбец базы данных должен обновлять все значения, используя convert_tz или аналогичный. Таким образом, должен быть написан либо скрипт mysql, либо скрипт grails, который загружает каждую строку для каждого класса, обновляя все поля времени.

Очевидно, что сервер должен быть удален, пока это происходит, и резервные копии должны быть установлены с ошибкой.

Есть ли лучший/более простой способ сделать это?

ответ

3

Java не использует часовые пояса при использовании Дат; он сохраняет все как UTC и использует только часовые пояса при отображении дат. см. следующую ссылку для обсуждения даты/времени java. http://www.odi.ch/prog/design/datetime.php

1

У нас были проблемы с временными различиями между использованием GORM и использованием groovy.sql.Sql (для быстрого импорта данных).

GORM был использование Grails конфигурации часового пояса (UTC), которые мы ставим в Bootstrap, но заводной SQL был с помощью системы по умолчанию часового поясу в (GMT).

Проблема была решена путем установки часового пояса в $ JAVA_OPTS, хотя вы можете добавить переключатель Граалей выбирает или команды выполнения приложения.

grails -Duser.timezone=UTC run-app

2

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

Во-первых, я использую Grails 2.5.1 и PostgreSQL 9.4 в качестве интерфейса.

Во-вторых, Поля даты в Groovy/Grails сохраняются как timestamp without time zone в PostgreSQL. Поэтому мне кажется, что первый ответ выше не совсем корректен - дата не сохраняется в UTC. Это наблюдение заставило меня задуматься ... в соответствии с «хорошо, если база данных не знает, что такое часовой пояс, кто это делает»? И первый ответ, который пришел на ум, был «может быть, это весна».

В-третьих, особенности моей проблемы в том, что у меня есть много дат, которые я загрузил в базу данных через BootStrap.groovy и new ThisClass().save().И поскольку это были даты, а не даты + времена, все они выглядят как 2005-11-03 00:00:00 как временные метки PostgreSQL (без часовых поясов).

В-четвертых, что действительно сделало падение пенни, когда я редактировал один из моих GSP, чтобы включить часовой пояс в строку формата даты, которая появилась как PST (где мой сервер); и когда я включил timeZone="Asia/Kolkata" в поле g:formatDate, время, указанное на 12h30. Настолько ясно, что мой сервер работал в PST8PDT, и поскольку это не был PostgreSQL, я вернулся к Spring как потенциальное место для изменения вещей.

В-пятых, после прочтения нескольких комментариев о настройке локали в grails-app/conf/spring/resources.groovy я решил попробовать установить локаль и часовой пояс там, в соответствии с:

// Place your Spring DSL code here 
beans = { 
    // from http://stackoverflow.com/questions/1569446/grails-how-to-change-the-current-locale 
    localeResolver(org.springframework.web.servlet.i18n.SessionLocaleResolver) { 
     defaultLocale = new Locale("en","IN") 
     java.util.Locale.setDefault(defaultLocale) 
     println "configure spring/resources.groovy defaultLocale $defaultLocale" 
     defaultTimeZone = TimeZone.getTimeZone("Asia/Kolkata") 
     java.util.TimeZone.setDefault(defaultTimeZone) 
     println "configure spring/resources.groovy defaultTimeZone $defaultTimeZone" 
    } 
} 

Я также использовал g:format timezone="Asia/Kolkata" format="dd MMM, yyyy a z" для всех моих полей даты. И это, кажется, интерпретировать все данные в PostgreSQL timestamp полей в правильной временной зоны и в ожидаемом час (т.е. час, который был введен), хотя сроки были введены первые «в неверном часовом поясе».

Шестой, g:datePicker - Я прочитал несколько сообщений о создании этого «часового пояса», но я обнаружил, что его даты интерпретируются как в часовом поясе, используемом весной, и поэтому в моем случае это именно то, что мне нужно , И наоборот, если кто-то захотел ввести даты в свой локаль и весна конвертировала их на лету в часовой пояс сервера, я думаю, это потребует дополнительных усилий.

Лично я думаю, что было бы здорово, если бы g:datePicker принял timeZone в качестве параметра и использовал его таким же образом g:formatDate.

Смежные вопросы