Joda-Time 사용에 대한 단점이 있습니까?

Joda-Time 사용에 대한 단점이 있습니까?

---

아키텍처 관리자가 제품에 Joda-Time jar 를 포함하도록 설득하고 싶습니다 .

사용시 단점을 알고 계십니까?

Joda-Time에 포함 된 파일 때문에 지속적으로 업데이트해야한다고 생각합니다. 그리고 그것은 단점입니다. 내가 틀렸을 수도 있습니다.

주제에 대해 명확하게 설명해 주시겠습니까?

---

나는 Joda Time에 대해 거의 완전히 긍정적 인 경험을했습니다. 내 한 가지 문제는 내 자신의 시간대를 만들려고 할 때였습니다. (합법적 인 이유로 확신합니다 :) 매우 이상한 예외가 있었고 문서는 특정 사용 사례에 적합하지 않았습니다.

그러나 대부분의 경우 사용하는 것이 즐거웠습니다. 불변성은 코드를 추론하기 훨씬 쉽게 만들고 포맷터의 스레드 안전성은 매우 유용합니다.

네, 최신 상태로 유지하는 파일입니다 -하지만 적어도 당신은 할 수 날짜로 유지. 자바의 내장 된 것들에 불필요한 것들을 포함하는 것이 아니라 자바의 메커니즘을 사용하면 중요한 해커 없이는 시간대와 같은 정보를 최신 상태로 유지할 수 없다는 것입니다!

기본적으로 Joda Time을 사용하면 +1입니다. Java 날짜 / 시간 API는 Java 플랫폼 인 IMO의 가장 나쁜 부분 중 하나입니다.

---

제 생각에 Joda-Time의 가장 중요한 단점은 정밀도에 관한 것입니다. 많은 데이터베이스는 마이크로 초 (또는 나노초 ) 정밀도로 타임 스탬프를 저장 합니다. Joda-time은 밀리 초에 불과합니다 . 이것은 나에게 허용되지 않습니다. 내가 사용하는 모든 "데이터 모델"클래스는 데이터베이스에있는 데이터의 전체 정밀도를 반영해야합니다. 라이브러리에 의한 내 데이터의 근사치 또는 절단은 그것을 자르지 않습니다.

다음은 JSR 310 메일 링리스트 에서 가져온 밀리 초 정밀도를 선택한 이유입니다 .

"Joda-Time은 날짜와 달력으로 쉽게 변환 할 수 있도록 밀리 초를 사용하기로 결정했습니다." -S. Colebourne

누구에게 더 쉬울까요? 라이브러리의 저자는 ... 제 생각에는 거의 모든 데이터베이스가 마이크로 초 / 나노초 정밀도로 시간을 저장할 때 잘못된 설계 결정을 내립니다. 데이터베이스 값에 대한 무시가 걱정입니다.

---

Joda Time을 사용할 때 가장 큰 문제는 Spring 및 Tapestry와의 통합이었습니다. 둘 다 내장 된 날짜 및 시간을 사용하기를 원했기 때문입니다. 우리는 날짜와 시간에 대해 getter / setter에 지속적으로 래퍼를 작성했습니다. Joda Time으로 저장하고 한 세트의 getter / setter가 전달하고 다른 하나는 즉석에서 변환하고 일부 클래스는 내부적으로 Java로 저장했습니다. 날짜 / 시간 및 Joda getter / setter는이를 즉석에서 전환해야했습니다.

기본적으로 클래스 이름이 비슷하기 때문에 골칫거리였습니다. 전체 아키텍처 (통합중인 다른 라이브러리 포함)를 Joda Time으로 전환 할 수없는 경우 저장하려는 것보다 더 많은 래퍼 코드를 작성하게됩니다. Joda 라이브러리를 사용하여.

---

Parleys는 Stephen Colebourne의 JSR-310 , Joda-Time 및 JSR-310의 저자 인 Mr. Colebourne에 대한 프레젠테이션을 진행합니다. 그는 Java의 표준 날짜 / 시간 지원의 약점과 대안을 사용하려는 이유를 설명하는 것으로 시작합니다. 이 프레젠테이션을 아키텍처 관리자에게 보여 주면 도움이 될 수 있습니다. 딥 링크가 안되는 것 같습니다

Joda-Time이 시간대 파일을 상당히 자주 업데이트하는 이유는 시간대 데이터가 항상 짧은 시간에 변경되고 (오늘날 slashdot : 윤초가 2008-12-31에 추가됨 ) 항상 과학적으로 동기가 부여 된 것은 아니기 때문입니다 (예 : 일부 태평양 섬 주가 2000 년에 진입 한 최초의 국가로 시간대를 변경했습니다.)

---

과거에는 타사 오픈 소스 소프트웨어를 통합하고 싶지 않거나 최소한 회사 변호사에게 라이선스가 어떤 종류의 책임에 노출되거나 바이러스에 노출되지 않는다는 것을 증명하도록 요구 한 회사를 만났습니다. 제품에 미치는 영향.

타사 라이브러리와 마찬가지로 소스 제어에 넣어야 문제가 발생할 경우 코드의 특정 릴리스와 함께 제공 한 버전을 찾을 수 있습니다.

---

기본 시간 연속체에 대한 밀리 초를 선택하면 고대 달력 및 특수 달력을 구현하는 데 좋습니다. 많은 카운터와 달리 64 비트 밀리 초 카운터는 +/- 2 억 6 천만 년을 초과하는 롤오버 속성으로 고대 달력에 대해 좋은 범위를 제공합니다.

윤초는 처리하지 않습니다. 이것은 좋은 일입니다. 윤초를 배치하지 않는 시스템이 윤초 수정을 수용하기 위해 100 초 이상 시계를 점진적으로 조정할 수 있도록 원자 시계 담당자는 원활한 전환을 제안합니다.

시간대 테이블의 유지 관리도 문제가됩니다.

기본 연속체는 또한 하루를 24 시간 대신 미터법 시간이라고하는 10 개의 간격으로 나눈 오래된 프랑스 달력 및 시계를 허용합니다. 고전적인 중국 달력은 하루를 각각 14 분을 조금 넘는 100 개 단위로 나눕니다. 이러한 모든 달력은 기본 밀리 초 시간 연속체에서 구현 및 조정할 수 있습니다.

---

그것의 주된 문제는 적어도 그것이 표준의 일부가 될 때까지 벤더 고정입니다.

대부분의 경우 데이터베이스에 비즈니스 날짜 정보를 저장하기 위해 longs를 사용합니다. 이것은 내가 적합하다고 생각하는대로 정밀도를 조정할 수있는 유연성을 제공합니다. 대부분의 경우 java.util.Date로 변환합니다.

데이터 문제 라기보다는 프레젠테이션 수준 문제로 취급 할 시간대입니다. 이것은 데이터베이스가 다른 방식으로 시간을 나타낼 수 있기 때문에 데이터베이스를 단순화하고 이식성을 증가시킵니다.

표준 Calendar 클래스는 epoch 데이터 이후 밀리 초로 변환하는 몇 가지 날짜 조작 함수를 제공합니다.

나노초 정밀도에 관해서는 0에서 오프셋으로 별도의 긴 열로 저장합니다.

참조 URL : https://stackoverflow.com/questions/375544/are-there-any-cons-to-using-joda-time