I had another look at this and still believe it was a test issue.

For TemporalType.TIME the current implementation converts the time part of the given date into String based on UTC. So e.g. the Date which denotes the point in time 2013-12-05T22:44:52.996+11:00 would be converted into the String 11:44:52.996Z. Note that a Date itself has no TZ, it is just used here for creating a human-readable representation in local time, here that's Australia).

When reading back this String, the year/month/date parts are implicitely assumed to be 1970-01-01. Now when creating a Calendar based on that time, using the same time zone as before (as it is done in the test), then this would be converted into 1970-01-01T21:44:52.996+10:00 (unlike Date, a Calendar is associated with a TZ). Note the difference of one hour. This is caused by the fact that the TZ used for creating a Calendar from the Date has an offset of 11 hours for the original date (comprising a raw offset of 10 and a daylight saving offset of 1), while this TZ has an offset of 10 hours for 1970-01-01 (just the raw offset of 10, no DST).

As a result one needs to be cautious when using TemporalType.TIME on Date, in particular one must know whether DST is included or not when reading back a given time. This is ensured when always using a Date with year/month/day set to 1970-01-01 for TemporalType.TIME properties.The test fix circumvents the issue by using UTC as default TZ.