에서 노다 시간 사용 설명서 , 근거 섹션 상태 :
공용 API는 .NET에 더 관용적 인 API를 제공하고 Noda Time 팀이 "불행한"것으로 간주하는 Joda Time 결정 중 일부를 수정하기 위해 크게 재 작성되었습니다. (이들 중 일부는 단순히 다른 목표를 가지고 있기 때문에, 다른 사람들은 실제로 실수라고 주장합니다.)
다른 / 더 나은 결정은 무엇입니까? 언어 구문의 차이 만 계산하지는 않지만 사용자가 프로그래밍 오류 (라이브러리 유용성)를 덜 발생시키기 위해 수행 한 모든 작업을 포함합니다.
답변:
시작하기 가장 좋은 곳은 아마도 사용자 안내서 의 "디자인 철학" 섹션 일 것입니다. 그러나 Noda Time과 Joda Time의 구체적인 차이점 을 설명하려면 다음을 수행하십시오.
Noda Time은 훨씬 더 많은 코드를 내부에 보관합니다. 따라서 실제로 자체 캘린더 시스템을 만들 수 없다는 점에서 유연성이 떨어집니다. 또한 API는 배우고 사용하기가 더 간단합니다.
Nullity는 Noda Time에서 거의 항상 오류입니다. 더 이상 "시간대에 null을 전달하면 시스템 기본값 만 사용합니다." 명시 적이어야합니다.
기본값으로 말하면 ... 시스템 시계를 기본값으로 사용하지 않습니다. 구현 IClock과 별도의 인터페이스가 SystemClock있지만 기본값은 "현재 시간"입니다.
특정 빌더 클래스 외에는 모든 것이 불변입니다. MutableDateTimeJoda Time의 (et al)은 실수 라고 생각 합니다.
캘린더 시스템과 시간대는 서로 매우 다른 관심사이므로 서로 분리되어 있습니다. 따라서 LocalDate예를 들어 시간대가 아닌 사용하는 캘린더 시스템에 대해 알고 있습니다.
지역 날짜 / 시간 값을 존 날짜 / 시간 값으로 해석하는 방법은 Joda Time보다 JSR-310에 더 가깝습니다. 우리는 특정한 방식으로 모호성 / 건너 뛰기 시간을 처리하는 것이 아니라 사용자가 원하는 것을 말하게합니다.
Joda Time에는 약한 유형의 API (예 : new Instant(Object)) 에서 원하는 것을 추측하려는 다양한 위치가 있습니다 . Noda Time은 가능한 한 이것을 피합니다. 훨씬 명확합니다.
Noda Time은 어떤 유형에 대해 어떤 종류의 산술을 수행 할 수 있는지가 더 엄격합니다. 예를 들어, 일광 절약 전환 주위에 문제가 생길 수 있기 때문에 Period를에 추가 할 수 없습니다 ZonedDateTime. 대신 사용자는로 변환하고 영역 LocalDateTime이없는 컨텍스트에서 원하는 산술을 많이 수행 한 다음 다시 변환하도록 권장합니다 .
Noda Time은 상속을 덜 사용합니다. Joda Time의 계층 구조는 매우 깊고 복잡합니다. 많은 Noda Time이 실제로 가치 유형을 기반으로한다는 사실은 실제로 어쨌든 이것을 시행하지만 여전히 클래스 상속을 사용하는 곳이 있지만 상속 계층 구조를 크게 축소 할 수 있습니다. 내가 가치가 없다고 생각한 유연성