> > In my opinion implementations should write the correct flag for future > proofness and check the flag when reading, but I don't think that both > types need to be supported, especially without proper language support.
Just to clarify we only expect "isAdjustedToUTC = false" flags to be written/read? On Mon, Jun 21, 2021 at 2:05 AM Zoltan Ivanfi <[email protected]> wrote: > Hi, > > The UTC normalization mechanism was created primarily with timestamps > (date + time) in mind. The flag was only added to pure times for the sake > of consistency. > > In my opinion implementations should write the correct flag for future > proofness and check the flag when reading, but I don't think that both > types need to be supported, especially without proper language support. > Personally I would handle encountering the other type as an error case (for > example: assertion error, not implemented or unsupported data type). > > Br, > > Zoltan > > On Wed, Jun 16, 2021 at 12:41 AM Micah Kornfield <[email protected]> > wrote: > >> It seems that Time has an isAdjustedToUTC flag [1] in the parquet.thrift, >> the current documentation covers the use of this flag clearly for >> Timestamp >> type [2], however given the explanation it isn't immediately clear to me >> how the flag should be interpreted for Time. For instance in Java [3] it >> doesn't appear there is a temporal analogue to LocalTime that includes any >> sort of timezone normalization. >> >> Could someone provide some examples? >> >> Thanks, >> Micah >> >> >> [1] >> >> https://github.com/apache/parquet-format/blame/master/src/main/thrift/parquet.thrift#L284 >> [2] >> >> https://github.com/apache/parquet-format/blob/master/LogicalTypes.md#timestamp >> [3] >> https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html >> >
