import java.time.LocalDate; import java.time.LocalDateTime; 차이는?

 

 

 

 

LocalDate

날짜만 담습니다. 연/월/일.

LocalDate date = LocalDate.now();
// 예: 2026-05-08

 

LocalDateTime

날짜 + 시간을 같이 담습니다. 연/월/일/시/분/초(+나노초).

LocalDateTime dateTime = LocalDateTime.now();
// 예: 2026-05-08T14:23:45.123

---

왜 굳이 나눠놨을까?

 

처음엔 "그냥 LocalDateTime 하나만 있으면 안 되나?" 싶은데, 실무에서 둘을 구분하는 게 훨씬 안전하고 깔끔하기 때문입니다.

 

1) 시간 정보가 필요 없는 데이터에 시간이 끼면 버그가 납니다

생일, 기념일, 입사일, 휴가 신청일 같은 건 "날짜"지 "몇 시 몇 분"이 아닙니다. 만약 LocalDateTime으로 저장하면:

LocalDateTime birthday1 = LocalDateTime.of(1990, 5, 8, 0, 0, 0);
LocalDateTime birthday2 = LocalDateTime.of(1990, 5, 8, 0, 0, 1);
// 같은 날 생일인데 1초 차이로 다른 값으로 취급됨
birthday1.equals(birthday2); // false

 

LocalDate를 쓰면 이런 실수가 원천 차단됩니다.

 

2) 타입이 의도를 드러냅니다

 

메서드 시그니처만 봐도 무슨 의미인지 명확해져요.

List<Order> findOrdersByDate(LocalDate date)       // 그날 하루치 주문
List<Order> findOrdersBefore(LocalDateTime moment) // 특정 시각 이전 주문

 

같은 "Date"라는 단어를 써도 의도가 다른 걸 타입이 알려줍니다.

 

3) DB 컬럼 타입과 1:1 매칭됩니다

• DB의 DATE 타입 ↔ Java의 LocalDate
• DB의 TIMESTAMP / DATETIME 타입 ↔ Java의 LocalDateTime

매핑이 자연스러워집니다.

 

4) 메모리도 살짝 절약되고 비교도 빠릅니다 (사소하긴 합니다)

---

참고: 더 있습니다

java.time 패키지에는 이런 것들이 더 있어요:

• LocalTime — 시/분/초만 (예: 영업 시작 시간 09:00)
• ZonedDateTime — 시간대(타임존)까지 포함 (예: 2026-05-08T14:23+09:00 KST)
• Instant — UTC 기준 타임스탬프, 서버 간 통신에 자주 씀
• Duration / Period — 기간 (몇 시간, 며칠)

각각 역할이 명확히 나뉘어 있어서, 상황에 맞는 걸 골라 쓰면 코드가 훨씬 안전해집니다. Java 8 이전의 java.util.Date 한 클래스가 모든 걸 다 처리하던 시절의 혼란을 의도적으로 정리한 설계예요.

---

한 줄 정리

• 시간이 의미 없으면 → LocalDate
• 시간까지 의미 있으면 → LocalDateTime
• 시간대(서울/뉴욕 등)까지 따져야 하면 → ZonedDateTime