ianmcook commented on code in PR #50146:
URL: https://github.com/apache/arrow/pull/50146#discussion_r4201377139


##########
cpp/src/arrow/csv/converter.cc:
##########
@@ -464,18 +472,93 @@ struct MultipleParsersTimestampValueDecoder : public 
ValueDecoder {
   }
 
  protected:
-  using ParserVector = std::vector<const TimestampParser*>;
+  TimeUnit::type unit_;
+  bool expect_timezone_;
+  std::vector<const TimestampParser*> parsers_;
+};
 
-  static ParserVector GetParsers(const ConvertOptions& options) {
-    ParserVector parsers(options.timestamp_parsers.size());
-    for (size_t i = 0; i < options.timestamp_parsers.size(); ++i) {
-      parsers[i] = options.timestamp_parsers[i].get();
+//
+// Value decoder for dates and times, with fallback to user-defined
+// timestamp parsers
+//
+
+// Tries the ISO-8601 format first, then the user-defined timestamp parsers.
+// A timestamp produced by a user-defined parser is floored to the day
+// boundary for dates, and reduced to the time of day for times (consistent
+// with casting a timestamp to date32/date64/time32/time64).
+template <typename T>
+struct DateTimeWithParsersValueDecoder : public ValueDecoder {
+  using value_type = typename T::c_type;
+
+  DateTimeWithParsersValueDecoder(const std::shared_ptr<DataType>& type,
+                                  const ConvertOptions& options,
+                                  const TrieCache* trie_cache)
+      : ValueDecoder(type, options, trie_cache),
+        concrete_type_(checked_cast<const T&>(*type)),
+        parse_unit_(GetParseUnit(concrete_type_)),
+        ticks_per_day_(TicksPerDay(parse_unit_)),
+        parsers_(GetTimestampParsers(options_)) {}
+
+  Status Decode(const uint8_t* data, uint32_t size, bool quoted, value_type* 
out) {
+    TrimWhiteSpace(&data, &size);
+    if (ARROW_PREDICT_TRUE(string_converter_.Convert(
+            concrete_type_, reinterpret_cast<const char*>(data), size, out))) {
+      return Status::OK();
+    }
+    for (const auto& parser : parsers_) {
+      int64_t timestamp = 0;
+      bool zone_offset_present = false;
+      if (parser->operator()(reinterpret_cast<const char*>(data), size, 
parse_unit_,
+                             &timestamp, &zone_offset_present) &&
+          !zone_offset_present) {
+        // Floor division, to handle values before the epoch
+        int64_t days = timestamp / ticks_per_day_;
+        days -= (timestamp % ticks_per_day_) < 0;
+        if constexpr (std::is_same_v<T, Date32Type>) {
+          *out = static_cast<value_type>(days);
+        } else if constexpr (std::is_same_v<T, Date64Type>) {
+          *out = days * kMillisPerDay;
+        } else {
+          static_assert(is_time_type<T>::value);
+          *out = static_cast<value_type>(timestamp - days * ticks_per_day_);
+        }
+        return Status::OK();
+      }
     }
-    return parsers;
+    return GenericConversionError(type_, data, size);
   }
 
-  TimeUnit::type unit_;
-  bool expect_timezone_;
+ protected:
+  static constexpr int64_t kMillisPerDay = 86400000;
+
+  static TimeUnit::type GetParseUnit(const T& type) {
+    if constexpr (is_time_type<T>::value) {
+      // Parse in the time type's own unit, so that the time of day can be
+      // extracted without further conversion
+      return type.unit();

Review Comment:
   Using the time type’s unit for the intermediate timestamp unnecessarily 
restricts `time64[ns]` to the `timestamp[ns]` date range.
   
   For example, with input `9999-12-31 07:55:00`:
   
   - Reading directly as `time64[ns]` fails with a conversion error.
   - Reading as `timestamp[s]` and casting to `time64[ns]` succeeds, producing 
`07:55:00.000000000`.
   
   I reproduced this with both `ISO8601` and `%Y-%m-%d %H:%M:%S`, and with year 
1600 as well. The resulting time of day is representable; the failure comes 
from scaling the entire timestamp to nanoseconds before discarding the date.
   
   Could we extract the time at a usable intermediate precision before scaling 
to the output unit, while preserving fractional precision? Regression tests 
with dates outside the nanosecond timestamp range would cover this.
   
   This failure occurs during parsing, so replacing the later multiplication 
with a normalized remainder won’t resolve it.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to