Good question. I'll take a stab at answering some of it.
C++ has the same passthru / interoperability concerns. Python is
significant as it's builtin datetime module distinguishes between
"local" and "instant" datetimes (which it calls naive and non-naive).
In addition, pandas which has a very
Thanks everyone for their input;
Interoperability would be the biggest issue; how much does C++ do with the
timezone string?
-Evan
> On Jul 7, 2021, at 1:33 PM, Weston Pace wrote:
>
> I don't know about removal but you could probably ignore the timezone
> string and it's not clear the issues
I don't know about removal but you could probably ignore the timezone
string and it's not clear the issues would be that significant.
If Rust never produces a non-null non-UTC timestamp then I don't see
that as an issue.
If you are consuming data with a timestamp string other than UTC it
isn't
On Wed, 7 Jul 2021 at 18:46, Jorge Cardoso Leitão
wrote:
> Hi,
>
> AFAIK timezone is part of the spec.
And for reference, the current spec (Schema flatbuffer file) for timestamp
is at
https://github.com/apache/arrow/blob/6c8d30ea8fd2750b999840872d3f6cbdc8f8/format/Schema.fbs#L217-L247.
Hi,
AFAIK timezone is part of the spec. In Python, that would be [1]
import pyarrow as pa
dt1 = pa.timestamp("ms", "+00:10")
dt2 = pa.timestamp("ms")
arrow-rs is not very consistent with how it handles it. imo that is an
artifact of being currently difficult (API wise) to create an array with a
Hi folks,
Some of us are having a discussion about a direction change for Rust Arrow
timestamp types, which current support both a resolution field (Ns, Micros, Ms,
Seconds) similar to the other language implementations, but also optionally a
timezone string field. I believe the timezone
