java.util.Date и проблема с UTC - PullRequest
Новая
       10

java.util.Date и проблема с UTC

1 голос
/ 11 мая 2011

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

У меня есть текущее время UTC в мс, которое мне нужно сравнить с текущимвремя в моей машине (поэтому они должны совпадать). 

long myUTCtime = .....; // This reflects the UTC time
// myDate is in UTC, ok, I agree
Date myDate = new Date();
// When I use getTime() I get the localtime in ms, although not in UTC! but in DST
long milis = myDate.getTime();
// I get here a 60 minute difference
long difference = milis - myUTCtime;

Как я могу это сделать?

Заранее спасибо.

РЕДАКТИРОВАТЬ: мне не нужнокалендарь или что-нибудь.Я не показываю информацию пользователю, я просто хочу использовать время UTC, и Дата должна быть ВСЕГДА в UTC

Ответы [ 6 ]

3 голосов
/ 11 мая 2011

leonbloy правильно.Вам не нужно делать какие-либо расчеты смещения. Date.getTime () возвращает количество миллисекунд с начала эпохи, без учета текущего часового пояса .Это сбивает с толку людей, потому что Date.toString () возвращает строку даты, используя ваш местный часовой пояс.

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

2 голосов
/ 11 мая 2011 
Date myDate = new Date();
long milis = myDate.getTime();

должно быть эквивалентно простому: 

long milis = System.currentTimeMillis();

Оба должны вернуть

разница, измеренная в миллисекунды, между текущим временем и полночь 1 января 1970 года по Гринвичу

Быстрая проверка в моем окне linux: 

# cat X.java
public class X { public static void main(String[] args) {
                System.out.println( (new java.util.Date()).getTime());
                System.out.println( System.currentTimeMillis());
        } }

# javac X.java ; java X ; perl -e 'print time()*1000'
1305133124654
1305133124654
1305133124000

Возможно, у вас есть проблема с толкованием ...

0 голосов
/ 21 января 2015

util.ate не имеет ничего общего с часовыми поясами, но я не уверен в этом. Так как у меня проблема с датой в разных зонах.

  1. Мой сервер в формате UTC берет дату из базы данных, хранящейся в качестве метки времени, и возвращает дату 2015-01-19 13: 19: 17.0. Это правильно, так как это то, что хранится в базе данных. Теперь я делаю .getTime () / 1000 этой даты и получаю 421673557 .
  2. Я делаю то же самое с другого сервера с датой CET. и дата 2015-01-19 13: 19: 17,0 ( то же самое ), но .getTime () / 1000 возвращает 1421669957 .

Так что это точно разница между часовыми поясами UTC и CET. Вы можете сделать то же самое, изменив местный часовой пояс.

Так что я думаю, что вы все не правы. Или openjdk и oracle sdk содержат ошибку.

Может кто-нибудь объяснить, пожалуйста?

0 голосов
/ 11 мая 2011

Date содержит количество миллисекунд с 1970 года, часовой пояс не используется: 

$ date +%s
1305133104
$ groovy -e "println System.currentTimeMillis() / 1000"
1305133106.155
$ groovy -e "println new Date().time / 1000"
1305133107.495
0 голосов
/ 11 мая 2011

Я не знаю, как вы заполняете myUTCtime, но new Date().getTime() или System.currentTimeMillis() возвращает количество миллисекунд с 1970-01-01 0:00 UTC. Если вы видите разницу с myUTCtime, я предполагаю, что myUTCtime неверно. Другими возможными вариантами являются, например, ваша операционная система настроена с неверным часовым поясом, поэтому другие методы дают вам неверные значения.

0 голосов
/ 11 мая 2011

Возможно, используя 

Calendar.get(Calendar.ZONE_OFFSET) + Calendar.get(Calendar.DST_OFFSET)) / (60 * 1000)

будет делать, как описано в этом устаревшем методе:

http://download.oracle.com/javase/6/docs/api/java/util/Date.html#getTimezoneOffset()

Посмотрите, работает ли это для вас.

...