Originally, we didn't allow int to date or long to timestamp, but we added those to support expression conversion from Spark. It's much easier to allow the LongLiteral created from a Spark timestamp expression directly to a TimestampLiteral than to convert to an equivalent timestamp string because the internal representation in Spark and Iceberg are the same. The conversion from long to date was never really needed by this path, so we probably didn't add it. Iceberg is fairly strict with allowed conversions to date and timestamp because the validation we can apply is still very permissive.
I think it's fine to add long to date if there is a need, but otherwise I'd leave it as it is. Do you have a use case for this? On Tue, Feb 18, 2020 at 3:19 PM Vlad Rozov <vro...@apache.org> wrote: > Hi, > > What is the reason iceberg does not allow LongLiteral to DateLiteral > conversion while allowing LongLiteral to IntegerLiteral and IntegerLiteral > to DateLiteral? Should not direct conversion from LongLiteral to > DateLiteral be allowed when LongLiteral represents values in a proper range? > > Thank you, > > Vlad -- Ryan Blue Software Engineer Netflix
