jrevels commented on issue #303: URL: https://github.com/apache/arrow-julia/issues/303#issuecomment-1066909783
I'd have to check [the implementation](https://github.com/apache/arrow-julia/blob/f88a62e0b6458ed6ea0439fc371f2e4ee0e039a7/src/eltypes.jl#L203-L209) more deeply but I assume it's just because Arrow Date <-> Julia Date translation reuses the same generic mechanisms/interface provided by ArrowTypes.jl instead of "special-casing" dates as a "built-in" type. I'm assuming we could add such special casing pretty easily (might as well), but I'm not sure it solves the underlying problem here - that consumers probably should be able to gracefully read any arrow types they support and probably remain agnostic to extension metadata that isn't within a "namespace" they're aware of/explicitly support (would be interesting to have the notion of namespaced metadata be formalized if it isn't already). this guidance might be worth upstreaming somewhere for consumer implementations if other folks find it sensible > Conversely, Arrow.jl should be able to read the Arrow date formats and convert them to the native Julia formats yup, this should definitely already work (if it doesn't, please file a ticket!) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
