Add some way to create a Timestamp from a `DateTime`

[alamb]

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
In DataFusion we have occasions where we have a chrono NiaveDateTime or DateTime and would like to create the corresponding Timestamp value (e.g. i64)

This came up recently in https://github.com/apache/datafusion/pull/19733/changes#r2742968186\\

Basically we want the API

fn date_to_scalar(date: NaiveDate, target_type: &DataType) -> Option<ScalarValue> {

We have Date32Type::from_naive_date(date) but couldn't find the equivalent of Timestamp types as well

I was hoping for something like TimestampSecondType::from_datetime or something but all I could find was

https://docs.rs/arrow/latest/arrow/array/types/struct.TimestampSecondType.html and https://docs.rs/arrow/latest/arrow/datatypes/trait.ArrowTimestampType.html

Instead we went with our own date/time parsing (see apache/datafusion#19733)

Describe the solution you'd like
Add an API so downstream crates can avoid having to do date/time/timestamp arithmetic to convert from a NiaveDate (or document the conversion better)

Describe alternatives you've considered

Additional context

[alamb]

@sdf-jkl notes https://github.com/apache/datafusion/pull/19733/changes#r2743833522

As for timestamp: dyn TimestampType::make_value() is using a NaiveDate, not DateTime. We'd still have to do some tz math to create an offset for NaiveDate. (if only there was an existing API to help...)

[codephage2020]

I will give it a try. The initial idea is to add the following method to the 4 timestamp types.

// For timezone-aware DateTime (handles offset automatically)
pub fn from_datetime<Tz: TimeZone>(datetime: DateTime<Tz>) -> i64;

[codephage2020]

take

[sdf-jkl]

@alamb @codephage2020

The current make_value API takes a NaiveDateTime and returns the UTC timestamp value in its TimeUnit.

impl ArrowTimestampType for TimestampMicrosecondType {
    const UNIT: TimeUnit = TimeUnit::Microsecond;

    fn make_value(naive: NaiveDateTime) -> Option<i64> {
        let utc = naive.and_utc();
        let micros = utc.timestamp().checked_mul(1_000_000)?;
        micros.checked_add(utc.timestamp_subsec_micros() as i64)
    }
}

In date_to_scalar case, we have a NaiveDate and want to convert to scalar.

I wonder if we should change the scope of the new API to something like with_timezone/to_timezone where with_timezone(naive: NaiveDateTime, tz: Option<Tz>) -> Option<i64>.

It would keep the same logic as make_value but also check if tz is Some() and use it instead of UTC. If None, fallback to UTC.
Would help reduce the code here:
https://github.com/apache/datafusion/pull/19733/changes#diff-6e1c7798dffd9a3d0f1b7a22bc2910330ed9681cba8e879677e24a66e7b26042R329-R346

[codephage2020]

I wonder if we should change the scope of the new API to something like with_timezone/to_timezone where with_timezone(naive: NaiveDateTime, tz: Option<Tz>) -> Option<i64>.

make sense to me , I plan to keep make_value for backward compatibility and add a new from_naive_datetime(naive: NaiveDateTime, tz: Option<&Tz>) -> Option<i64> method

This naming is consistent with from_naive_datetime and from_datetime.

[alamb]

I think one good test would be "can we use this function in any places in DataFusion (or a similar project)". If we can't use it to replace existing functions we may have to keep iterating on the API