그럼 계속 진행하겠습니다. 날짜 다음 엔터티는 LocalTime 클래스 로 표시되는 시간입니다 . 전형적인 예는 상점의 영업 시간(예: 7:00부터 23:00)을 나타내는 것입니다. 현재 전국 매장 오픈 시간은 시간대에 따라 달라질 수 있습니다. LocalTime은 연관된 날짜나 시간대 없이 시간만 저장하는 값 클래스입니다. 기간을 더하거나 빼면 자정에 끊어집니다. 즉, 20:00에 6시간을 더하면 2:00가 됩니다. LocalTime을 사용하는 것은 LocalDate 와 유사합니다 . 수정자는 LocalTimeLocalTime time = LocalTime.of(20, 30); int hour = date.getHour(); // 20 int minute = date.getMinute(); // 30 time = time.withSecond(6); // 20:30:06 time = time.plusMinutes(3); // 20:33:06 과 함께 작동할 수 있지만 시간 작업은 일반적으로 수정자가 필요할 정도로 복잡하지 않습니다.
날짜와 시간 결합
다음으로 살펴볼 클래스는
LocalDateTime 입니다 .
이 값 클래스는 LocalDate 와
LocalTime 의 조합입니다 . 시간대 없이 날짜와 시간을 모두 나타냅니다.
LocalDateTime은 직접 생성하거나 날짜와 시간을 결합하여 생성할 수 있습니다.
LocalDateTime dt1 = LocalDateTime.of(2014, Month.JUNE, 10, 20, 30); LocalDateTime dt2 = LocalDateTime.of(date, time); LocalDateTime dt3 = date.atTime(20, 30); LocalDateTime dt4 = date.atTime(time); 세 번째와 네 번째 옵션은 날짜와 시간을 결합하는 유연한 방법을 제공하는
atTime() 메서드를 사용합니다. 대부분의 날짜 및 시간 시스템 클래스에는 개체를 다른 개체와 결합하여 더 복잡한 개체를 만들 때 사용할 수 있는 "at" 메서드가 있습니다.
LocalDateTime 클래스 의 다른 메서드는
LocalDate 및
LocalTime 의 메서드와 유사합니다 .
비슷한 메소드 이름 지정 패턴을 사용하면 API를 더 쉽게 배울 수 있습니다 . 이 표에는 관련된 모든 메소드 접두사가 나열되어 있습니다.
즉각적인
날짜와 시간을 다룰 때 일반적으로 연, 월, 일, 시, 분, 초를 사용합니다. 그러나 이것은 '인간'이라고 부를 수 있는 시간의 한 모델일 뿐이다. 일반적으로 사용되는 두 번째 모델은 "기계" 또는 "연속" 시간입니다. 이 모델에서는 시간 축의 한 지점을 하나의 큰 숫자로 표현합니다.
이 접근 방식은 계산 알고리즘을 단순화하고 Unix 운영 체제 에서 시간을 저장하는 데 사용됩니다 . 여기서 시간은 1970년 1월 1일 이후 경과된 초 수로 표시됩니다. 마찬가지로
Java 에서는 시간이 1970년 1월 1일 이후 경과한 밀리초 단위로 저장됩니다.
java.time API 의 시간 계산에 대한 기계 접근 방식은
Instant 값 클래스 에서 제공됩니다 . 시간대 등 수반되는 모든 정보 없이 시간 축의 한 지점을 나타내는 기능을 제공합니다. 실제로 이 클래스에는 1970년 1월 1일 자정 이후 경과한 나노초 수가 포함되어 있습니다.
Instant start = Instant.now(); // произведем вычисления Instant end = Instant.now(); assert end.isAfter(start); //машина времени не сработала 일반적으로
Instant 클래스 는 일부 이벤트가 발생한 시기를 저장해야 하지만 해당 이벤트가 발생한 시간대는 신경 쓰지 않는 경우 특정 시점을 저장하고 비교하는 데 사용됩니다.
대부분의 경우 Instant 클래스 로 할 수 있는 것보다 Instant 클래스로 할 수 없는 것이 더 흥미롭습니다 . 예를 들어, 다음 코드 줄은 예외를 발생시킵니다.
인스턴트 객체 는 나노초 수만 저장하고 인간에게 더 유용한 시간 단위로 작업하는 기능을 제공하지 않기 때문에
instant.get(ChronoField.MONTH_OF_YEAR); instant.plus(6, ChronoUnit.YEARS); 예외가 발생합니다 . 다른 측정 단위를 사용하려면 최소한 시간대를 지정해야 합니다.
시간대
시간대의 원리는 철도의 발명과 기타 통신 수단의 발전으로 사람들이 태양시의 차이를 눈에 띄게 느낄 수 있을 만큼 충분한 거리를 여행할 수 있게 되면서 영국에서 개발되었습니다. 이때까지 각 마을과 도시는 해시계로 가장 자주 측정되는 고유한 시간에 따라 살았습니다. 이 사진은 이로 인해 초래된 어려움의 예를 보여줍니다. 시계의 빨간색 바늘은 그리니치 시간을 나타내고, 검은색 바늘은 10분 차이가 나는 현지 시간을 나타냅니다. 현지 태양시를 대체하는 시간대 시스템이 개발되었습니다
. 그러나 중요한 사실은 시간대가 정치인에 의해 만들어지며, 지역에 대한 정치적 통제를 보여주기 위해 종종 사용된다는 것입니다. 모든 정책과 마찬가지로 시간대와 관련된 규칙은 논리를 무시하는 경우가 많습니다. 또한 이러한 규칙은 예고 없이 변경될 수 있으며, 종종 변경될 수 있습니다. 시간대 규칙은
IANA 시간대 데이터베이스를 발행하는 국제 그룹에 의해 작성됩니다 . 여기에는 지구의 각 지역에 대한 식별자가 포함되어 있으며 이에 대한 시간대 변경 내역이 포함되어 있습니다.
식별자는 “Europe/London” 또는
“America/New_York” 과 같습니다 .
java.time API가 출시되기 전에는
TimeZone 클래스가 시간대를 나타내는 데 사용되었습니다 .
이제 ZoneId가 대신 사용됩니다 . 그들 사이에는 두 가지 주요 차이점이 있습니다. 첫째,
ZoneId 는 변경할 수 없으므로 무엇보다도 이 클래스의 개체를 정적 변수에 저장할 수 있습니다. 둘째, 규칙 자체는
ZoneId 자체 가 아닌
ZoneRules 클래스에 저장되며 규칙 을 가져오려면
ZoneId 클래스 객체 에서
getRules() 메서드를 호출해야 합니다 . 모든 시간대의 공통적인 특징은
UTC/그리니치 와의 고정 오프셋입니다 . "뉴욕은 런던보다 5시간 늦습니다."와 같이 여러 도시 간의 시차를 말할 때 이 표현을 가장 자주 사용합니다.
ZoneId 의 자손인
ZoneOffset 클래스는 런던의 그리니치를 통과하는 본초 자오선과의 시간 차이를 나타냅니다. 개발자의 관점에서는 시간대와 그 복잡성을 다룰 필요가 없다는 것이 좋습니다.
java.time API를 사용 하면 가능한 한 이 작업을 수행할 수 있습니다. 가능하다면
LocalDate, LocalTime, LocalDateTime 및
Instant 클래스를 사용하십시오 . 시간대 없이는 할 수 없는 경우
ZonedDateTime 클래스를 사용하세요 .
ZonedDateTime 클래스
달력과 시계에 표시되는 인간 측정 단위의 날짜와 시간을 기계 단위로 변환할 수 있습니다. 결과적으로
Local 클래스나
Instant 클래스 에서
ZonedTimeDate를 만들 수 있습니다 . 시간대의 가장 불쾌한 기능 중 하나는 소위 일광 절약 시간입니다. 일광 절약 시간제를 그리니치로 전환하면 그리니치와의 시간대 차이가 1년에 두 번(또는 그 이상) 변경됩니다. 일반적으로 봄에는 늘어나고 가을에는 줄어듭니다. 이런 일이 생기면 우리 집 시계를 모두 바꿔야 해요.
java.time 클래스 에서 오프셋 데이터는
"오프셋 변환" 으로 표시됩니다 . 이로 인해 봄에는 일부 시간 값이 불가능할 때 시간에 "간격"이 발생하고, 가을에는 반대로 일부 시간 값이 두 번 발생합니다. 이 모든 것은 팩토리 메서드와 변환기 메서드를 통해
ZonedDateTime 클래스에서 지원됩니다. 예를 들어, 하루를 추가하면 논리적인 날짜가 추가되며, 일광 절약 시간으로 전환하거나 다시 전환하면 24시간 이상 또는 이하로 표시될 수 있습니다.
마찬가지로, atStartOfDay() 메소드의 이름은 하루가 정확히 자정에 시작된다고 보장할 수 없기 때문에 명명되었습니다. 일광 절약 시간제로 전환할 때 시간 차이를 고려해야 합니다. 일광 절약 시간제에 관한 마지막 팁입니다. 여름에서 겨울로 전환하는 동안(동일한 시간 값이 두 번 나타나는 경우) 시간 중복을 고려했음을 입증하려면 이러한 상황에 맞게 설계된 두 가지 특별한 방법 중 하나를 사용할 수 있습니다. value , 여름에서 겨울로 전환되는 동안 객체가 겹쳐지는 경우. 다른 모든 상황에서는 반환 값이 동일합니다.
ZoneId zone = ZoneId.of("Europe/Paris"); LocalDate date = LocalDate.of(2014, Month.JUNE, 10); ZonedDateTime zdt1 = date.atStartOfDay(zone); Instant instant = Instant.now(); ZonedDateTime zdt2 = instant.atZone(zone); zdt = zdt.withEarlierOffsetAtOverlap(); zdt = zdt.withLaterOffsetAtOverlap();
시간 간격
이전에 논의한 모든 클래스는 타임라인의 지점으로 작동합니다. 시간 간격을 나타내려면 두 개의 추가 값 클래스가 필요합니다.
Duration 클래스는 초와 나노초 단위로 측정된 시간 길이를 나타냅니다. 예를 들어 '23.6초'입니다.
Period 클래스는 연, 월, 일 단위로 측정된 기간을 나타냅니다. 예를 들어 '3년 2개월 6일'입니다. 날짜나 시간에서 이러한 간격을 더하거나 뺄 수 있습니다.
Period sixMonths = Period.ofMonths(6); LocalDate date = LocalDate.now(); LocalDate future = date.plus(sixMonths);
형식화 및 구문 분석
전체 패키지는 날짜와 시간(
java.time.format) 의 형식을 지정하고 표시하도록 설계되었습니다 . 패키지는
DateTimeFormatter 클래스 와 해당
DateTimeFormatterBuilder 팩토리를 중심으로 진행됩니다 . 포맷터를 생성하는 가장 일반적인 방법은 다음을 포함하여
DateTimeFormatter 의 정적 메서드와 상수를 사용하는 것입니다 .
ISO_LOCAL_DATE와 같이 ISO에 설명된 일반 형식에 대한 상수입니다.
ofPattern("dd/MM/uuuu")와 같이 문자로 식별되는 패턴입니다.
ofLocalizedDate(FormatStyle.MEDIUM)와 같은 지역화된 스타일.
포맷터를 생성한 후에는 일반적으로 이를 적절한 날짜 클래스 메소드에 전달하여 사용합니다.
DateTimeFormatter f = DateTimeFormatter.ofPattern("dd/MM/uuuu"); LocalDate date = LocalDate.parse("24/06/2014", f); String str = date.format(f); 이렇게 하면 날짜 출력 포맷을 담당하는 코드가 별도의 클래스로 격리됩니다. 날짜 형식 지정을 위한 로캘을 별도로 지정해야 하는 경우
withLocale(Locale) 형식 지정 메서드를 사용하세요 . 달력, 시간대, 분수 입력/출력을 담당하는 클래스에도 비슷한 방법이 있습니다. 더 많은 세부 조정 옵션이 필요한 경우 복잡한 포맷터를 단계별로 생성할 수 있는
DateTimeFormatterBuilder 클래스에 대한 설명서를 참조하세요. 또한 대소문자를 구분하지 않는 텍스트 구문 분석을 설정하고, 일부 구문 분석 오류를 무시하고, 오프셋 및 선택적 요소를 설정할 수 있습니다.
결론
java.time API는 Java SE 8 에서 날짜 및 시간 작업을 위한 새로운 포괄적인 모델입니다 .
Joda-Time 의 아이디어와 구현을 다음 단계로 끌어올려 개발자가
java.util.Date 및
Calendar 사용을 피할 수 있게 해줍니다 . 이제 날짜와 시간을 다루는 것이 재미있을 수 있습니다!
. 그러나 중요한 사실은 시간대가 정치인에 의해 만들어지며, 지역에 대한 정치적 통제를 보여주기 위해 종종 사용된다는 것입니다. 모든 정책과 마찬가지로 시간대와 관련된 규칙은 논리를 무시하는 경우가 많습니다. 또한 이러한 규칙은 예고 없이 변경될 수 있으며, 종종 변경될 수 있습니다. 시간대 규칙은
IANA 시간대 데이터베이스를 발행하는 국제 그룹에 의해 작성됩니다 . 여기에는 지구의 각 지역에 대한 식별자가 포함되어 있으며 이에 대한 시간대 변경 내역이 포함되어 있습니다.
식별자는 “Europe/London” 또는
“America/New_York” 과 같습니다 .
java.time API가 출시되기 전에는
TimeZone 클래스가 시간대를 나타내는 데 사용되었습니다 .
이제 ZoneId가 대신 사용됩니다 . 그들 사이에는 두 가지 주요 차이점이 있습니다. 첫째,
ZoneId 는 변경할 수 없으므로 무엇보다도 이 클래스의 개체를 정적 변수에 저장할 수 있습니다. 둘째, 규칙 자체는
ZoneId 자체 가 아닌
ZoneRules 클래스에 저장되며 규칙 을 가져오려면
ZoneId 클래스 객체 에서
getRules() 메서드를 호출해야 합니다 . 모든 시간대의 공통적인 특징은
UTC/그리니치 와의 고정 오프셋입니다 . "뉴욕은 런던보다 5시간 늦습니다."와 같이 여러 도시 간의 시차를 말할 때 이 표현을 가장 자주 사용합니다.
ZoneId 의 자손인
ZoneOffset 클래스는 런던의 그리니치를 통과하는 본초 자오선과의 시간 차이를 나타냅니다. 개발자의 관점에서는 시간대와 그 복잡성을 다룰 필요가 없다는 것이 좋습니다.
java.time API를 사용 하면 가능한 한 이 작업을 수행할 수 있습니다. 가능하다면
LocalDate, LocalTime, LocalDateTime 및
Instant 클래스를 사용하십시오 . 시간대 없이는 할 수 없는 경우
ZonedDateTime 클래스를 사용하세요 .
ZonedDateTime 클래스
달력과 시계에 표시되는 인간 측정 단위의 날짜와 시간을 기계 단위로 변환할 수 있습니다. 결과적으로
Local 클래스나
Instant 클래스 에서
ZonedTimeDate를 만들 수 있습니다 . 시간대의 가장 불쾌한 기능 중 하나는 소위 일광 절약 시간입니다. 일광 절약 시간제를 그리니치로 전환하면 그리니치와의 시간대 차이가 1년에 두 번(또는 그 이상) 변경됩니다. 일반적으로 봄에는 늘어나고 가을에는 줄어듭니다. 이런 일이 생기면 우리 집 시계를 모두 바꿔야 해요.
java.time 클래스 에서 오프셋 데이터는
"오프셋 변환" 으로 표시됩니다 . 이로 인해 봄에는 일부 시간 값이 불가능할 때 시간에 "간격"이 발생하고, 가을에는 반대로 일부 시간 값이 두 번 발생합니다. 이 모든 것은 팩토리 메서드와 변환기 메서드를 통해
ZonedDateTime 클래스에서 지원됩니다. 예를 들어, 하루를 추가하면 논리적인 날짜가 추가되며, 일광 절약 시간으로 전환하거나 다시 전환하면 24시간 이상 또는 이하로 표시될 수 있습니다.
마찬가지로, atStartOfDay() 메소드의 이름은 하루가 정확히 자정에 시작된다고 보장할 수 없기 때문에 명명되었습니다. 일광 절약 시간제로 전환할 때 시간 차이를 고려해야 합니다. 일광 절약 시간제에 관한 마지막 팁입니다. 여름에서 겨울로 전환하는 동안(동일한 시간 값이 두 번 나타나는 경우) 시간 중복을 고려했음을 입증하려면 이러한 상황에 맞게 설계된 두 가지 특별한 방법 중 하나를 사용할 수 있습니다. value , 여름에서 겨울로 전환되는 동안 객체가 겹쳐지는 경우. 다른 모든 상황에서는 반환 값이 동일합니다.
GO TO FULL VERSION