Я пытаюсь проанализировать дату, возвращаемую как значение из поля ввода HTML5 datetime. Попробуйте в Opera увидеть пример. Полученная дата выглядит следующим образом: 2011-05-03T11:58:01Z.
Я хотел бы проанализировать это в Java Date или Calendar Object.
В идеале решение должно иметь следующие вещи:
Только что обнаружил, что Google реализовал парсер Rfc3339 в клиентской библиотеке Google HTTP
Проверено. Это работает хорошо, чтобы разобрать изменяющийся фрагмент времени секунд.
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;
import java.util.Date;
import com.google.api.client.util.DateTime;
DateTimeFormatter formatter = DateTimeFormatter
.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'")
.withZone(ZoneId.of("UTC"));
@Test
public void test1e9Parse() {
String timeStr = "2018-04-03T11:32:26.553955473Z";
DateTime dateTime = DateTime.parseRfc3339(timeStr);
long millis = dateTime.getValue();
String result = formatter.format(new Date(millis).toInstant());
assert result.equals("2018-04-03T11:32:26.553Z");
}
@Test
public void test1e3Parse() {
String timeStr = "2018-04-03T11:32:26.553Z";
DateTime dateTime = DateTime.parseRfc3339(timeStr);
long millis = dateTime.getValue();
String result = formatter.format(new Date(millis).toInstant());
assert result.equals("2018-04-03T11:32:26.553Z");
}
@Test
public void testEpochSecondsParse() {
String timeStr = "2018-04-03T11:32:26Z";
DateTime dateTime = DateTime.parseRfc3339(timeStr);
long millis = dateTime.getValue();
String result = formatter.format(new Date(millis).toInstant());
assert result.equals("2018-04-03T11:32:26.000Z");
}
Instant.parse( "2011-05-03T11:58:01Z" )
На самом деле RFC 3339 - это всего лишь самопровозглашенный "профиль" действующего стандарта ISO 8601.
RFC отличается тем, что он намеренно нарушает ISO 8601, что допускает отрицательное смещение нуля часов (-00:00), и придает этому семантическое значение "смещение неизвестно". Эта семантика кажется мне очень плохой идеей. Я советую придерживаться более разумных правил ISO 8601. В ISO 8601 отсутствие смещения вообще означает, что смещение неизвестно - очевидное значение, тогда как правило RFC является заумным.
Современные классы java.time по умолчанию используют форматы ISO 8601 при разборе/генерации строк.
Ваша входная строка представляет момент в UTC. Буква Z в конце означает сокращение от Zulu и означает UTC.
Instant (не Date) Современный класс Instant представляет момент в UTC. Этот класс заменяет java.util.Date и использует более точное разрешение наносекунд, а не миллисекунд.
Instant instant = Instant.parse( "2011-05-03T11:58:01Z" ) ;
ZonedDateTime (не Calendar) Чтобы увидеть тот же самый момент через часы настенного времени, используемые людьми определенного региона (часового пояса), примените ZoneId чтобы получить ZonedDateTime. Этот класс ZonedDateTime заменяет класс java.util.Calendar.
ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
ZonedDateTime zdt = instant.atZone( z ) ; // Same moment, same point on the timeline, different wall-clock time.
Я настоятельно рекомендую по возможности избегать устаревших классов даты и времени. Но если вам нужно взаимодействовать со старым кодом, который еще не обновлен до java.time, вы можете конвертировать туда и обратно. Вызовите новые методы, добавленные к старым классам.
Instant заменяет java.util.Date.
java.util.Date myJUDate = java.util.Date.from( instant ) ; // From modern to legacy.
Instant instant = myJUDate.toInstant() ; // From legacy to modern.
ZonedDateTime заменяет GregorianCalendar.
java.util.GregorianCalendar myGregCal = java.util.GregorianCalendar.from( zdt ) ; // From modern to legacy.
ZonedDateTime zdt = myGregCal.toZonedDateTime() ; // From legacy to modern.
Если у вас есть java.util.Calendar который на самом деле является GregorianCalendar, выполните приведение.
java.util.GregorianCalendar myGregCal = ( java.util.GregorianCalendar ) myCal ; // Cast to the concrete class.
ZonedDateTime zdt = myGregCal.toZonedDateTime() ; // From legacy to modern.
Что касается ваших вопросов конкретных вопросов...
Классы java.time встроены в Java 8, 9, 10 и более поздние версии. Реализация также включена в более позднюю версию Android. Для более ранней версии Java и более ранней версии Android см. Следующий раздел этого ответа.
Различные классы java.time обрабатывают все известные мне форматы ISO 8601. Они даже обрабатывают некоторые форматы, которые таинственным образом исчезли из более поздних выпусков стандарта.
Для других форматов смотрите методы parse и toString различных классов, таких как LocalDate, OffsetDateTime и т.д. Кроме того, поиск, так как есть много примеров и обсуждений на эту тему.
Чтобы проверить входные строки, перехватите DateTimeParseException.
try {
Instant instant = Instant.parse( "2011-05-03T11:58:01Z" ) ;
} catch ( DateTimeParseException e ) {
… handle invalid input
}
Инфраструктура java.time встроена в Java 8 и более поздние версии. Эти классы вытеснять неприятные старые устаревшие классы даты и времени, такие как java.util.Date, Calendar, и SimpleDateFormat.
Проект Joda-Time, находящийся сейчас в режиме обслуживания, рекомендует перейти на классы java.time.
Чтобы узнать больше, смотрите Oracle Tutorial. И поиск для многих примеров и объяснений. Спецификация JSR 310.
Вы можете обмениваться объектами java.time напрямую с вашей базой данных. Используйте драйвер JDBC, соответствующий JDBC 4.2 или более поздней версии. Нет необходимости в строках, нет необходимости в java.sql.*.
Где взять классы java.time?
Проект ThreeTen-Extra расширяет java.time дополнительными классами. Этот проект является полигоном для возможных будущих дополнений к java.time. Здесь вы можете найти некоторые полезные классы, такие как Interval, YearWeek, YearQuarter и другие.
Итак, в принципе это было бы сделано с использованием различных шаблонов SimpleDateFormat.
Вот список шаблонов для отдельных объявлений в RFC 3339:
yyyyMMddHHMMss.SSS (S означает миллисекунду, хотя - неясно, что произойдет, если их будет больше или меньше 3 цифр.)+02:00, похоже, не поддерживается - вместо этого он поддерживает форматы +0200, GMT+02:00 и некоторые именованные часовые пояса с использованием z и z.)'Z' (не поддерживая другие часовые пояса) - вы должны использовать format.setTimezone(TimeZone.getTimeZone("UTC")), прежде чем использовать это.)HH:mm:ss или HH:mm:ss.SSS.HH:mm:ss'Z' или HH:mm:ss.SSS'Z'.yyyy-MM-ddyyyy-MM-dd'T'HH:mm:ss'Z' или yyyy-MM-dd'T'HH:mm:ss.SSS'Z'Как мы видим, это, похоже, не в силах разобрать все. Может быть, было бы лучше реализовать RFC3339DateFormat с нуля (с использованием регулярных выражений для простоты или анализа вручную).
Здесь - простой способ сделать это. Это может удовлетворить ваши потребности.
Возможно, не самый изящный способ, но, безусловно, тот, который я недавно сделал:
Calendar cal = Calendar.getInstance();
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd-HH:mm:ss");
cal.setTime(sdf.parse(dateInString.replace("Z", "").replace("T", "-")));
В формате, который у вас есть, например. 2011-05-03T11: 58: 01Z, ниже код будет делать. Тем не менее, я недавно проверил html5 datetime в Chrome и Opera, это дало мне 2011-05-03T11: 58Z → не имеет ss-части, которая не может быть обработана кодом ниже.
new Timestamp(javax.xml.datatype.DatatypeFactory.newInstance().newXMLGregorianCalendar(date).toGregorianCalendar().getTimeInMillis());
Date date = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'").parse(datetimeInFRC3339format)