Wei-Ting Kuo

> > 2. add another 2 ISO 8601 formats > > I personally lean towards only supporting one, especially if Chrono only supports one. https://xkcd.com/1179/ https://xkcd.com/927/ agree, the current one...

> In general, I would be a big fan of trying if possible of having datafusion normlize all data on input to UTC prior to processing but I worry this...

> When we are done with the discussion, perhaps we can close this issue and use #3148 as the coordination point for development i think we could close it for...

depends on apache/arrow-rs#1936

i'm interested in this, please assign me, thanks~

@alamb after investigating more on postgresql's, i found that we have following differences: ### Differences 1. postgresql is using microsecond for the resolution of timestamp, `datafusion` is using nanoseconds This...

@alamb should we consider `to_timestamp()` to output `timestamp with time zone`? in postgresql `select timestamp '2020-01-01'` output `timestamp without time zone` but `to_timestamp()` output `timestamp with time zone`.

@alamb i could image that might breaks lots of thing there're some time zone issues in datafusion for now as well e.g. #3080

@alamb after spend time figuring out how postgresql is working, i submitted a proposal here #3100 probably we need to deal with datatype `date / time / timestamp / time...

thank you @stuartcarnie ! note that time64 cannot be compared yet as there's no implementation in the [kernel](https://github.com/apache/arrow-rs/blob/master/arrow/src/compute/kernels/comparison.rs#L1897).