[Java] getObject API for temporal types is inconsistent and in some cases incorrect

It seems that the work which has been tracked in ARROW-2015 and merged in to change the return types of the various Time and Date vector types when using the getObject API missed some of the vector types which are temporal and so should return a temporal type, and provided an incorrect implementation for others (some of this was pointed out in the initial PR review, but it seems that it slipped through the cracks and was not addressed before merging).

Here is a table of the various temporal vector types, what they currently return from getObject, and what they should return, in my opinion (I have included ones in which the implementation is correct for completeness, and coloured them green).

|Vector class|Current return type|Proposed return type|Comments|
|
|-|-|-|-|-|
|DateDayVector|Integer|LocalDate|Currently returns the raw value of days since epoch, should return the actual date|
|
|DateMilliVector|LocalDateTime|LocalDate|This type is supposed to encode a date, not a datetime, so even though epoch millis are used, the result should be a LocalDate|
|
|DurationVector|Duration|Duration|Correct.|
|
|IntervalDayVector|Duration|Period|As per , Interval should be a calendar-based datatype, not a time-based one. This is represented in Java by a Period type. However, I note that the Java Period class does not support milliseconds, unlike the Arrow type, which might be why Duration is being returned. Some discussion may be needed on the best way to deal with this.|
|
|IntervalYearVector|Period|Period|Correct.|
|
|TimeMicroVector|Long|LocalTime|Currently returns the raw number of micros, should return the actual time|
|
|TimeMilliVector|LocalDateTime|LocalTime|Currently returns a datetime on 1970-01-01 with the correct time component, should just return the time|
|
|TimeNanoVector|Long|LocalTime|Currently returns the raw number of nanos, should return the actual time|
|
|TimeSecVector|Integer|LocalTime|Currently returns the raw number of seconds, should return the actual time|
|
|TimeStampMicroVector|LocalDateTime|LocalDateTime|Correct.|
|
|TimeStampMilliVector|LocalDateTime|LocalDateTime|Correct.|
|
|TimeStampNanoVector|LocalDateTime|LocalDateTime|Correct.|
|
|TimeStampSecVector|LocalDateTime|LocalDateTime|Correct.|
|
|TimeStampMicroTZVector|Long|ZonedDateTime|Currently returns the underlying micros, and TZ has to be obtained separately. Should return the actual datetime with timezone|
|
|TimeStampMilliTZVector|Long|ZonedDateTime|Currently returns the underlying millis, and TZ has to be obtained separately. Should return the actual datetime with timezone|
|
|TimeStampNanoTZVector|Long|ZonedDateTime|Currently returns the underlying nanos, and TZ has to be obtained separately. Should return the actual datetime with timezone|
|
|TimeStampSecTZVector|Long|ZonedDateTime|Currently returns the underlying seconds, and TZ has to be obtained separately. Should return the actual datetime with timezone|



I am happy to submit a PR to fix this if there is no other reason for this to persist other than these types being rarely used, but note that these would all be breaking API changes.



 |

**Reporter**: [Matt Jadczak](https://issues.apache.org/jira/browse/ARROW-9915)

_{**Note**: *This issue was originally created as [ARROW-9915](https://issues.apache.org/jira/browse/ARROW-9915). Please see the [migration documentation](https://github.com/apache/arrow/issues/14542) for further details.*}

首先定位所列时间向量类的 getObject 实现，并检查 ARROW-2015 和 pull request 2966 中的变更。在决定 Java 返回类型之前，检查 Arrow interval schema，尤其是 IntervalDayVector 的毫秒表示。完成的标准是：受影响的向量一致地返回所提议的时间类型，并且每个已更改的映射都有覆盖。

由索引模型根据 Issue 内容生成。