2016-03-15 2 views
2

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

  • Если говорить о сегодняшнем событии формат, как это: 20:45
  • Если говорить о завтрашнем событии формат: завтра 20: 45
  • И если они говорят о другой день формат is: 10 мая 2016

Поэтому я хотел бы знать, могу ли я проанализировать три из них с тем же DateFormat, если не то, что будет лучшим способом.

DateFormat format = new SimpleDateFormat("EEEE d ' de' MMMM ' de' yyyy", locale); 
+0

Какую версию Java вы используете? – Mirco

+0

Нет, вы не можете разобрать их с тем же экземпляром DateFormat, поскольку это ожидает, что значение будет проанализировано с заданным форматом. Если вы уверены, что это единственные форматы, которые вы можете получить, вы можете сначала проверить длину строки == 5, если это сегодня, после чего проверьте, включает ли строка «завтра», и если ни одна из них не была правдой, вы можете отформатировать ее с DateFormat. –

ответ

-2
if (DateFormat.charAt(0).isDigit() && DateFormat.charAt(1).isDigit() && DateFormat.charAt(2).isLetterOrDigit()==false .... { 
new String SimpleDateFormat= '15.03.2016'; 
else { 

if (DateFormat.charAt(0).isLetter('t') && DateFormat.charAt(1).isLetter('o') && and so on 
{ SimpleDateFormat='16.03.2016' 

и вы можете изменить состояние на 1 1 символ, чтобы соответствовать все тип форматов данных

+2

Пожалуйста, предоставьте хотя бы OP компилируемый код. – Spotted

-1

Вы не можете использовать один и тот же SimpleDateFormat для разбора всех типов, а также не будет хорошей практикой ни, не читаемый и более сложные, не добавляя никакого особого значения, я не хотел бы попробовать что-то вроде этого:

private static final SimpleDateFormat formatHHMM = new SimpleDateFormat("hh:mm"); 
private static final SimpleDateFormat formatOther = new SimpleDateFormat("MMM dd yyyy"); 

private static String convertDate(Date curDate) { 
    if (isToday(curDate)) { 
     return formatHHMM.format(curDate); 
    } 
    else if (isTomorrow(curDate)) { 
     return "Tomorrow " + formatHHMM.format(curDate); 
    } 
    return formatOther.format(curDate); 
} 

private static boolean isToday(Date curDate) { 
    Date today = Calendar.getInstance().getTime(); 
    return today.equals(curDate); 
} 

private static boolean isTomorrow(Date curDate) { 
    Calendar calendar = Calendar.getInstance(); 
    calendar.add(Calendar.DATE, 1); 
    Date tomorrow = calendar.getTime(); 
    return tomorrow.equals(curDate); 
} 
//Check the code with this 
public static void main(String[] args) 
{ 
    Date curDate = new Date(); 
    System.out.println(convertDate(curDate)); 

    Calendar calendar = Calendar.getInstance(); 
    calendar.add(Calendar.DATE, 1); 
    Date tomorrow = calendar.getTime(); 
    System.out.println(convertDate(tomorrow)); 

    calendar = Calendar.getInstance(); 
    calendar.add(Calendar.DATE, 15); 
    Date other = calendar.getTime(); 
    System.out.println(convertDate(other)); 
} 
+1

Я думаю, что OP хотел найти решение ** разбора ** разных форматов даты, а не ** формата **. – Spotted

-1

Я не думаю, что можно разобрать 3 формат с тем же форматировщиком. Хотя может быть возможно проанализировать первые два только с одним форматированием, разница в значении (сегодня или завтра) будет означать другую логику, которая не может быть получена с помощью одного форматирования.

I suggest вы к handle each case separately, trying one after another:

try { 
     return LocalDate 
       .now() 
       .atTime(LocalTime.parse(date)); 
    } catch (DateTimeParseException e) { 
     try { 
      return LocalDate 
        .now() 
        .plusDays(1) 
        .atTime(LocalTime.parse(date, DateTimeFormatter.ofPattern("'tomorrow' HH:mm"))); 
     } catch (DateTimeParseException e1) { 
      return LocalDate 
        .parse(date, DateTimeFormatter.ofPattern("MMMM dd yyyy", Locale.ENGLISH)) 
        .atStartOfDay(); 
     } 
    } 

Я'm не sure about в clarity части в flow control, though. Если число входных форматов растет, может потребоваться рефакторинг в нечто более четкое.

+0

Ну, мне не нравится поток управления за исключением catch, но это не ваша ошибка (здесь вызывается ограничения API). В любом случае, производительность будет страдать, это точно. –

+0

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

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