Здравствуйте, mazurkin, Вы писали:
M>mazurkin wrote:
>> 2. Использовать для вывода DateFormat (DateFormat, SimpleDateFormat)
M>... и устанавливать свою нужную тайм-зону в его параметрах.
$ cat DateTest.java
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.TimeZone;
public class DateTest {
public static void main(String[] args) {
Calendar c = Calendar.getInstance();
c.setTimeZone(TimeZone.getTimeZone("Europe/Moscow"));
System.out.println(c.getTime());
SimpleDateFormat f = new SimpleDateFormat("dd.MM.yyyy HH:mm:ss");
f.setTimeZone(TimeZone.getTimeZone("Europe/Moscow"));
System.out.println(f.format(c.getTime()));
}
}
$ javac DateTest.java
$ java DateTest
Fri Feb 27 15:19:32 GMT 2009
27.02.2009 18:19:32
Т.е. Calendar я не могу указать тайм-зону, а для SimpleDateFormat, получается, могу. Все бы ничего, но Calendar.getTime() мне надо сохранять в БД, а переводить его для этого в строку несколько стремно ...
Здравствуйте, ENP, Вы писали:
ENP>Т.е. Calendar я не могу указать тайм-зону, а для SimpleDateFormat, получается, могу. Все бы ничего, но Calendar.getTime() мне надо сохранять в БД, а переводить его для этого в строку несколько стремно ...
так и сохраняй спокойно как дату, или, как иногда бывает удобнее, как long millis
переводить в строку надо только при выводе на экран
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, ENP, Вы писали:
ENP>>Т.е. Calendar я не могу указать тайм-зону, а для SimpleDateFormat, получается, могу. Все бы ничего, но Calendar.getTime() мне надо сохранять в БД, а переводить его для этого в строку несколько стремно ...
C0s>так и сохраняй спокойно как дату, или, как иногда бывает удобнее, как long millis C0s>переводить в строку надо только при выводе на экран
Так вот и ломал голову, отчего в БД сохраняется не то, пока не соорудил это test case
Да, в постгресе был timestamp without timezone и это вполне устраивало — видимо не понимал глубины проблемы . А Calendar мне он нужен был для операций с датами и временем (ну там увеличить текущую дату/время на час или на месяц с учетом разного количества дней в месяцах и т.д.) — а тут выходит, что все эти операции будут считаться в UTC, а не в локальном времени. Хоть прям переноси эти операции на уровень СУБД
Здравствуйте, ENP, Вы писали:
ENP>Здравствуйте, C0s, Вы писали:
C0s>>Здравствуйте, ENP, Вы писали:
ENP>>>Т.е. Calendar я не могу указать тайм-зону, а для SimpleDateFormat, получается, могу. Все бы ничего, но Calendar.getTime() мне надо сохранять в БД, а переводить его для этого в строку несколько стремно ...
C0s>>так и сохраняй спокойно как дату, или, как иногда бывает удобнее, как long millis C0s>>переводить в строку надо только при выводе на экран
ENP>Так вот и ломал голову, отчего в БД сохраняется не то, пока не соорудил это test case
ENP>Да, в постгресе был timestamp without timezone и это вполне устраивало — видимо не понимал глубины проблемы . А Calendar мне он нужен был для операций с датами и временем (ну там увеличить текущую дату/время на час или на месяц с учетом разного количества дней в месяцах и т.д.) — а тут выходит, что все эти операции будут считаться в UTC, а не в локальном времени. Хоть прям переноси эти операции на уровень СУБД
Или хак в виде TimeZone.setDefault() и все-таки timestamp without timezone в СУБД
Здравствуйте, ENP, Вы писали:
ENP>Да, в постгресе был timestamp without timezone и это вполне устраивало — видимо не понимал глубины проблемы . А Calendar мне он нужен был для операций с датами и временем (ну там увеличить текущую дату/время на час или на месяц с учетом разного количества дней в месяцах и т.д.) — а тут выходит, что все эти операции будут считаться в UTC, а не в локальном времени. Хоть прям переноси эти операции на уровень СУБД
1) Надо осознать для себя как часовой пояс влияет на время в базе, и на клиентах. Особенно когда клиенты в разных поясах.
2) И вот уже после осознания необходимо аккуратно продумать все операции, те которые должны зависить от часового пояса и те которые не должны.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, ENP, Вы писали:
ENP>>Да, в постгресе был timestamp without timezone и это вполне устраивало — видимо не понимал глубины проблемы . А Calendar мне он нужен был для операций с датами и временем (ну там увеличить текущую дату/время на час или на месяц с учетом разного количества дней в месяцах и т.д.) — а тут выходит, что все эти операции будут считаться в UTC, а не в локальном времени. Хоть прям переноси эти операции на уровень СУБД B>1) Надо осознать для себя как часовой пояс влияет на время в базе, и на клиентах. Особенно когда клиенты в разных поясах. B>2) И вот уже после осознания необходимо аккуратно продумать все операции, те которые должны зависить от часового пояса и те которые не должны.
Дело в том, что клиенты будут в одном часовом поясе. И никакие операции зависеть от него не должны. Но с Calendar и UTC это, похоже, малой кровью невозможно
Здравствуйте, ENP, Вы писали:
ENP>Дело в том, что клиенты будут в одном часовом поясе. И никакие операции зависеть от него не должны. Но с Calendar и UTC это, похоже, малой кровью невозможно
А ты представь, что в разных. Это очень необходимо для понимания происходящего. И перестань оверквотить.
Здравствуйте, ENP, Вы писали:
ENP>Здравствуйте, ENP, Вы писали:
ENP>>Или хак в виде TimeZone.setDefault() и все-таки timestamp without timezone в СУБД
ENP>А глобально установить тайм-зону все равно не выйдет: как минимум, FreeMarker хочет, что ему ее установили персонально
ENP>Гады ... Скажите, куда идти вешать баг. Есть шанс, что в Sun прислушаются?
. А Calendar мне он нужен был для операций с датами и временем (ну там увеличить текущую дату/время на час или на месяц с учетом разного количества дней в месяцах и т.д.) — а тут выходит, что все эти операции будут считаться в UTC, а не в локальном времени. Хоть прям переноси эти операции на уровень СУБД 
