来自 LocalDate 和字符串的 Joda LocalDateTime

Question

I have:

• a joda LocalDate , so it has no time information and just date
• a string which contains time and zone information, like "14:20 CEST"

Either of them can be absent (Scala's Option ).

How can I combine these two to get joda LocalDateTime , ie entity representing only date and time with no timezone?

Answer 1

To combine these 2 options, the natural way is to use flatMap method like this:

val onlyDateOption: Option[LocalDate] = ???
val timeAndZoneOption: Option[String] = ???

val result: Option[LocalDateTime] = onlyDateOption.flatMap { onlyDate => 
  timeAndZoneOption.map { timeAndZone =>
    // Some logic here to build the LocalDateTime from onlyDate and timeAndZone
  }
}

Which can also be written with for-comprehension in more readible way:

val result: Option[LocalDateTime] =  for {
  onlyDate <- onlyDateOption
  timeAndZone <- timeAndZoneOption
} yield { 
  // Some logic here to build the LocalDateTime from onlyDate and timeAndZone
}

Now, how to use Joda to build what you're expecting can probably be done in various different ways, one could be:

onlyDate
  .toLocalDateTime(LocalTime.MIDNIGHT)
  .withHourOfDay(...) // hour extracted from the string somehow
  .withMinuteOfHour(...) // minute extracted from the string somehow

I'm not familiar with Joda API, there is probably another easier way

Answer 2

How to combine LocalDate and String using Joda-Time

You have already got an answer treating the use of Option in detail. Here I want to go into more detail with the combination of your LocalDate and your String into a LocalDateTime using Joda-Time. I understand that you are getting a Joda-Time LocalDate from legacy code and need to return a Joda-Time LocalDateTime to legacy code. I am assuming that you know the time zone the abbreviation of which is in the string. I think that you should validate that abbreviation since Central European Time uses the abbreviation CET during the standard time part of the year and CEST during summer time (DST). Excuse my Java code.

    DateTimeUtils.setDefaultTimeZoneNames(createTimeZoneNamesMap());
    DateTimeFormatter timeFormatter = DateTimeFormat.forPattern("H:mm z");
    
    LocalDate date = new LocalDate(2021, 5, 22);
    String timeAndZoneString = "14:20 CEST";
    
    LocalTime time = LocalTime.parse(timeAndZoneString, timeFormatter);
    DateTime dateTime = date.toDateTime(time, ZONE);
    
    // Validate time zone abbreviation; take overlap at fall-back into account
    String earlierCorrectTimeString = dateTime.withEarlierOffsetAtOverlap()
            .toString(timeFormatter);
    if (! timeAndZoneString.equals(earlierCorrectTimeString)) {
        String laterCorrectTimeString = dateTime.withLaterOffsetAtOverlap()
                .toString(timeFormatter);
        if (! timeAndZoneString.equals(laterCorrectTimeString)) {
            throw new IllegalStateException("Incorrect time zone abbreviation for date");
        }
    }
    
    LocalDateTime ldt = dateTime.toLocalDateTime();
    
    System.out.println(ldt);

Output:

2021-05-22T14:20:00.000

I have used these two auxiliary declaration:

private static final DateTimeZone ZONE = DateTimeZone.forID("Europe/Paris");

private static Map<String, DateTimeZone> createTimeZoneNamesMap() {
    Map<String, DateTimeZone> names = new HashMap<>(4);
    names.put("CET", ZONE);
    names.put("CEST", ZONE);
    return names;
}

The validity of the time on the date is also validated: date.toDateTime() validates that the resulting DateTime would not fall in the gap at the spring-forward and throws an IllegalInstantException: if it would.

If the hours you receive in the string are always two digits, the format pattern string needs to specify this, so HH:mm z .

Please be aware that you are losing information in a corner case: If the time falls in the overlap at fall-back, the time zone abbreviation disambiguates, but the LocalDateTime that you produce is ambiguous. For example the date is 2021-10-31 and the time string is 2:20 CEST . Then we know that the time is in the summer time part of the year, that is, before the clocks are turned back. You return 2021-10-31T02:20:00.000, and the receiver won't be able to tell whether to understand it as 2021-10-31T02:20:00.000+02:00 (summer time) or 2021-10-31T02:20:00.000+01:00 (standard time).