I agree with storing it as a long. How would you handle this in code generation and serialization? Would you envision hooks during code generation that would generate a member that is the native date time for the language? Does the serializer handle a date object that is native to the language? I really like the idea of having a standard datetime as a supported type of avro. It's a problem that everyone has to solve on their own.
On Tue, Jan 18, 2011 at 10:42 AM, Doug Cutting <[email protected]> wrote: > The way that I have imagined doing this is to specify a standard schema for > dates, then implementations can optionally map this to a native date type. > > The schema could be a record containing a long, e.g.: > > {"type": "record", "name":"org.apache.avro.lib.Date", "fields" : [ > {"name": "time", "type": "long"} > ] > } > > Java could read this into a java.util.Date, Python to a datetime, etc. Such > conventions could be added to the Avro specification. > > Does this sound like a reasonable approach? > > Doug > > On 01/17/2011 05:54 PM, Ron Bodkin wrote: >> >> Has anyone discussed the possibility of having built-in support for a >> date/time stamp data type in Avro? I think it'd be helpful, since dates >> and timestamps are often used as keys in processing map/reduce data (and >> in RPC systems). It's unpleasant to have to write code that converts >> longs or strings into dates or timestamps. Minimally, it would be useful >> to allow generating date/time stamps from long timestamps in the client >> APIs various language code and to have support for working with Dates in >> the Java reflection API. >> >> I'd like to get feedback from others if they'd also like to see support >> for date/time data types in Avro. It seems like a generally useful >> feature that would be worth adding with a patch. >> >> Thanks, >> Ron >> >> Ron Bodkin >> CEO >> Think Big Analytics >> m: +1 (415) 509-2895 >> >> >
