Odd results in Joda DateTime for 01.04.1893

Question

My time zone is CET (Berlin).
And while testing Joda's DateTime i noticed some strange things:

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

A 6 minute 32 seconds shift in the time zone resulting in a non-existent time??
I must say this is highly unexpected since i didn't specify any time zone info and thus didn't expect to run into this kind of problem.
If in March of 1893 CET (Berlin) doesn't exist - why doesn't new DateTime(1893, 3, 31, 0, 0, 0, 0) pick the time zone that matches the time i specified (i.e. 0 minutes and 0 seconds)?

What are my options to get the correct time with DateTime?

-- EDIT --
The problem seems to be the toDate(). I had edited it out before posting the question.
Joda itself actually works fine:

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

It's just that the conversion to Date moves part of the offset into the minutes and seconds.

Answer 1

If you don't specify a time zone, unfortunately Joda Time uses the system one. And yes, Berlin really did change at that time (and by 6 minutes and 32 seconds). So you were specifying a local time which didn't exist.

What do you mean by "why doesn't [...] pick the time zone that matches the time I specified?" - the time zone affects how local time is mapped to UTC. In the time zone you implicitly specified (by letting it pick your system default) that time didn't exist; no UTC instant maps to that local time. There are any number of time zones which would map that local time - how would Joda know which one to pick?

I agree that using the system default time zone is a bad move on Joda's part (and one we fixed in Noda Time) but all the rest of the behaviour is absolutely fine. (Noda Time has a specific exception for this exactly situation to distinguish it from passing in values which are more obviously bad, but there we go.)

If you don't want time zones to enter into it at all then you should use a LocalDateTime instead.