2016-08-19 7 views
0

Я понимаю, что Date.getTime() в Java вернет миллины с EPOCH, учитывая дату как дату UTC.Получение миллисов, так как EPOCH в дате UTC возвращает неправильные результаты?

На Java 6 у меня есть дата, на которой, если я выполняю Date.getTime(), он возвращает миллисеты с EPOCH, учитывая, что Date находится в часовом поясе PDT. (Сервер, на котором я запускаю код, настроен на время PDT.)

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

Ниже мой фрагмент кода и выход:

logger.debug("Date: " + someDate); 
logger.debug("someDate in millis): " + someDate.getTime()); 

Output:                           
Date: 2016-08-19 12:04:56.993 
someDate in millis: 1471633496993 //This is time since EPOCH for 2016-08-19 12:04:56.993 PDT 

, тогда как я хочу, чтобы вернуть Миллис в качестве 1471608296993 (1471608296993 является Миллисекунды ЭПОХИ для UTC Дата: 2016-08-19 12: 04: 56,993)

Короче говоря, я хочу получить миллины с EPOCH, независимо от местного часового пояса, что в моем случае является PDT.

Пожалуйста, помогите.

+0

Можете ли вы добавить код, в котором вы создаете 'someDate'? – jonhopkins

+0

Я получаю «someDate» из базы данных SQL-сервера – user2306856

+0

Является ли база данных возвращением даты с информацией о часовом поясе? – jonhopkins

ответ

0

Используя информацию от this answer до this question, я смог придумать код, который будет правильно разобрать ваш String в качестве даты в UTC. Хитрость заключается в том, чтобы использовать SimpleDateFormat объект для разбора String перед созданием Date объекта:

String strDate = "2016-08-19 12:04:56.993"; 
SimpleDateFormat isoFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS"); 
isoFormat.setTimeZone(TimeZone.getTimeZone("UTC")); 
Date date = isoFormat.parse(strDate); 
System.out.println(date); 
System.out.println(date.getTime()); 

Выход:

Fri Aug 19 08:04:56 EDT 2016 
1471608296993 
+0

Спасибо jonhopkins. Это помогло решить проблему. Я попробовал вышеупомянутое решение, прежде чем публиковать вопрос, но думаю, что я больше концентрировался на формате даты, отображаемом в качестве вывода, что я не понимал, что миллисы верны. Но это помогло мне понять, что Дата, отображаемая в System.out.println, использует локальный часовой пояс для отображения результатов. – user2306856

2

В соответствии с Java Doc getTime()

Возвращает количество миллисекунд, прошедших с 1 января 1970, 00:00:00 GMT

Он не использует местный часовой пояс

+0

Да, это то, что я читал повсюду.Но если вы видите вывод, который я получаю, похоже, это не так. – user2306856

+0

Похоже, что объект Date, о котором идет речь, принимает предоставленную String и рассматривает его как время в часовом поясе по умолчанию OP и за кулисами, преобразуя его в UTC. 12:04 PDT - это не то же самое, что 12:04 UTC, на самом деле это 19:04 UTC, следовательно, разница в ожидаемом и фактическом выходе. – jonhopkins

+0

используйте созданные миллисекунды и проверьте здесь http://www.epochconverter.com/ – ravthiru

1

Дополнительно к тому, что уже было сказано johnhopkins.

A Date объект хранит время в milliseconds since January 1, 1970, 00:00:00 GMT. Но когда вы распечатаете его, он будет напечатан как дата вашего текущего часового пояса.

Следующий фрагмент демонстрирует это.

Calendar cal = GregorianCalendar.getInstance(TimeZone.getTimeZone("UTC")); 
cal.set(Calendar.YEAR, 2016); 
cal.set(Calendar.MONTH, Calendar.AUGUST); 
cal.set(Calendar.DAY_OF_MONTH, 19); 
cal.set(Calendar.HOUR_OF_DAY, 12); 
cal.set(Calendar.MINUTE, 4); 
cal.set(Calendar.SECOND, 56); 
cal.set(Calendar.MILLISECOND, 993); 

long epochMillis = cal.getTime().getTime(); 
System.out.println("EPOCH millis = " + epochMillis); 
System.out.println("date from cal = " + cal.getTime()); 
Date date = new Date(epochMillis); 
System.out.println("date from epoch = " + date); 

выход

EPOCH millis = 1471608296993 
date from cal = Fri Aug 19 14:04:56 CEST 2016 
date from epoch = Fri Aug 19 14:04:56 CEST 2016 

Две линии date from ... печатать дату 2016-08-19 12:04:56.993 UTC используя часовой пояс по умолчанию.

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

  • Нет связанных вопросов^_^