Joda DateTime의 이상한 결과는 01.04.1893입니다.

Question

내 시간대는 CET (베를린)입니다.
그리고 테스트 Joda의 날짜 시간 좀 이상한 일들 발견하면서 32 초 존재하지 않는 시간에 발생하는 시간대에 이동

new DateTime(1893, 4, 1, 0, 0, 0, 0); 
=> java.lang.IllegalArgumentException: Illegal instant due to time zone offset transition: 

new DateTime(1893, 3, 31, 0, 0, 0, 0).toDate(); 
=> Fri Mar 31 00:06:32 CET 1893 

6 분 ??
시간대 정보를 지정하지 않았으므로 이런 종류의 문제가 발생할 것으로 예상하지 않았기 때문에 이것은 매우 예상치 못한 일입니다.
1893 년 3 월 CET (Berlin)이 존재하지 않는 경우 - new DateTime(1893, 3, 31, 0, 0, 0, 0)은 내가 지정한 시간 (즉 0 분 0 초)과 일치하는 시간대를 선택하지 않는 이유는 무엇입니까?

DateTime을 사용하여 올바른 시간을 얻는 방법은 무엇입니까?

- EDIT -
문제는 toDate() 인 것 같습니다. 나는 질문을 게시하기 전에 그것을 편집했다.
Joda 자체는 실제로 잘 작동 :

는

new DateTime(1893, 3, 31, 0, 0, 0, 0); 
=> 1893-01-01T00:00:00.000+00:53:28 

이 날짜로의 전환은 분, 초에의 오프셋 (offset)의 일부를 이동하는 단지입니다.

Answer 1

시간대를 지정하지 않으면 Joda Time에서 시스템을 사용합니다. 그리고 그때 베를린 really did change (그리고 6 분 32 초). 그래서 당신은 존재하지 않았던 현지 시간을 지정하고있었습니다.

"내가 지정한 시간과 일치하는 표준 시간대를 선택하지 않은 이유는 무엇입니까?" - 시간대는 현지 시간이 UTC에 매핑되는 방법에 영향을줍니다. 시간대에 암시 적으로이 지정됩니다 (시스템 기본값을 선택하게 함으로서 시간이 존재하지 않음). UTC 인스턴트는 해당 현지 시간으로 매핑되지 않습니다. 은 현지 시간으로지도를 표시하는 시간대가 여러 개 있습니다. Joda가 어느 것을 골라야하는지 어떻게 알 수 있습니까?

나는 시스템 기본 시간대를 사용하는 것이 Joda의 일부분 (그리고 우리는 Noda Time에 고정 된 것)에 나쁜 영향을 주지만 모든 나머지 동작은 절대적으로 괜찮음에 동의합니다. (노다 시간은 더 분명 나쁜 값을 전달 구별이 정확히 상황에 대한 특정 예외를 가지고 있지만, 우리는 거기에 가지.)

당신이 시간대가 모든 그것을 을 체결하지 않을 경우 대신 LocalDateTime을 사용해야합니다.

Answer 2

new DateTime(1893, 4, 1, 0, 0, 0, 0, DateTimeZone.UTC);으로 항목을 인스턴스화하려고 했습니까?