Java Date - 라이브러리 필요성

날짜와 시간을 다루는 계산은 복잡하며 어렵다. 개발자는 날짜와 시간 관련된 라이브러리를 사용할 수 밖에 없다. 왜 그런지 살펴보자.

날짜와 시간이 어려운 이유

• 날짜와 시간 차이에 대한 처리 필요
  • 특정 날짜부터 다른 날까지 정확한 일수 계산이 복잡하게 엮어 있다.
  • 윤년, 각 달의 일마다 고려하며 뺄셈으로는 정확한 결과를 얻기 어려움
  • 1월 1일부터 3월 1일까지의 년도마다 다를 수 있어서 계산이 복잡하다.
• 윤년 계산하기
  • 지구의 태양을 한 바퀴는 평균 시간 365.242일이라 한다. 365일 하고 5시간 48분이다. 날짜로만 계산하면 정확한 시간이 맞지 않다는 것을 알 수 있다.
  • 날짜 계산 문제 해결이 필요해 4년마다 하루를 추가하는 윤년(leap year)이 있다. 예로 2월은 28일까지 있지만, 4년마다 한번은 29일 하루 더 추가해야 했다.
  • 윤년 계산을 4년마다 하루 더 추가하는 것으로 부족하다. 100년 단위인 경우 윤년이 아니기도 하며 400년 마다 다시 윤년이 찾아온다.
  • 2000년과 2020년은 윤년, 1900년 2100년은 윤년이 아님.
• 일광 절약 시간 변환(Daylight Saving Time, DST)
  • 3월부터 10월은 태양이 일찍 뜨며 나머지는 태양이 늦게 뜬다. 이에 맞춰 하루 일과를 1시간 앞당기거나 늦추는 제도가 있으며 이를 썸머타임 또는 일광 절약 시간제이다. 국가와 지역에 따라 적용이 되기도 안되기도 하며 적용되는 곳은 시작과 종료 날짜가 다르다.
  • 특정 지역은 3월 말 일요일은 DST 시작되며 10월의 마지막 일요에 종료한다. 이 기간 동안 시간과 날짜는 1시간 추가 및 빼는 로직이 있어야 한다.
• 국가 타임 존 계산하기
  • 세계적으로 다양한 타임존으로 나누어져 있고, UTC(협정 세계시)로부터 시간을 정의하였다.타임존마다 날짜와 시간 변환을 정확한 계산이 복잡하다

타임존

목록

• UTC
  • 00:00
• GMT
  • 00:00
• US / Arizona
  • -07:00
• America / NewYork
  • -05:00
• Asia / Seoul
  • +09:00
• Asia / Dubai
  • +04:00
• Asia / Shanghai
  • +08:00
• Europe / London
  • 00:00
• Europe / Paris
  • +01:00
• Europe / Berlin
  • +01:00

모두 표기하지 않았으나 많은 타임존이 있다.

표준 시간대

London / UTC / GMT 세 타임존은 00:00 표준으로 정해졌다.

GMT (그리니치 표준시, Greenwich Mean Time)

세계 시간을 처음 만들 때 영구 런던의 그리니치 천문대 기준으로 하였다. 태양이 그리니치 천문대를 통과한 시간을 정오로 한다.

UTC (협정 세계시, Universal Time Coordinated)

UTC 도 마찬가지로 0도에 위치한 영국의 그리니치 천문대 기준으로 시간이 맞춰져 있다. GMT 와 두 시간 체계 시간 정의하고 유지 방법 차이가 있다.
원자 시계를 사용해 측정한 국제적으로 합의된 시간 체계로 지구의 자전 속도가 변화하는 것을 고려한 윤초를 추가 또는 빼는 방식으로 시간을 조정하였다. 정확한 시간을 유지하기에 국제적 표준은 UTC 으로 선호되고 있다.

타임존에서 주의할 점

• 일광 절약 시간(DST)
  • 일광 절약 시간 적용 시 타임존 문제가 있다. 베를린은 DST가 적용되며 UTC+1 이 아닌 UTC+2 가 되어 타임존 계산이 변하게 된다.

이러한 복잡성을 고려한 잘 설계된 라이브러리를 잘 선택해야 한다. 개발자는 복잡한 계산을 추상화하여 타임존 시간을 제공에 필요하다. 안정적이고 정확한 코드로 작성이 요구된다.

자바 날짜와 시간의 역사

레거시 프로젝트를 진행하는 분야에서 문제가 있던 날짜 라이브러리가 사용하고 있을 수 있다. 자바에서 일어난 날짜와 시간 처리에 대한 업데이트를 살펴보자.

• JDK 1.0 (java.util.Date)
  • 문제 발생
    • 타임존 처리 부족. 초기 Date 클래스 타임존(time zone) 처리가 미흡했다.
    • 불편한 날짜 시간 연산. 날짜 간 연산 및 시간 증감 처리가 어려웠다.
    • 불변 객체 부재. Date 객체가 변경 가능한 mutable이었으며, 데이터가 쉽게 변화되고 버그가 쉽게 발생하였다.
  • 해결책
    • JDK 1.1 에서 java.util.Calender 클래스 도입하여 타임존 지원
    • 메소드로 날짜 시간 연산 추가
• JDK 1.1 (java.util.Calender)
  • 문제 발생
    • 사용성 저하. Calender 사용이 복잡하며 직관적이지 않다.
    • 성능 문제. 일부 사용 사례에서 성능이 저하되었다.
    • 불변 객체 부재. Calender 객체가 변경 가능하여 스레드 안전 및 사이드 이펙트가 생겨났다.
  • 해결책
    • Joda-Time 오픈소스 라이브러리 사용으로 성능, 사용성, 불변 문제 해결
• Joda-Time
  • 문제 발생
    • 표준 라이브러리가 아니었음. 오픈소스 라이브러리로 프로젝트를 추가하여야 했다.
  • 해결책
    • Java 8 공식적으로 java.time 패키지 API로 도입함(JSR-310)
• JDK 8 (java.time 패키지)
  • API 도입으로 문제를 해결하고 java.time 표준 패키지로 제공되어 사용성, 성능, 스레드 안전성, 타임존 처리에 개선되었다. 날짜와 시간 연산을 단순화되었다.
  • LocalDate, LocalTime, LocalDateTime, ZonedDateTime, Instant 클래스 포함
  • Joda-Time 많은 기능을 자바 플랫폼으로 사용되었다.

정리

• 자바 표준이었던 Date, Calender 사용성이 떨어지고 문제가 많았다.
• 이후 개선된 Joda-Time 오픈소스 라이브러리가 나왔고 편리함과 사용성으로 대중화 되었다.
• 자바는 날짜와 시간 설계 문제를 인정하고 Joda-Time 개발자에게 JSR-310 새로운 자바 표준 날짜와 시간 라이브러리를 정의하였다.