[
https://issues.apache.org/jira/browse/AVRO-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986730#action_12986730
]
Ron Bodkin commented on AVRO-739:
---------------------------------
Sorry I forgot to pate in Doug Cutting's design:
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?
And also this email thread -
On 01/18/2011 09:19 AM, Jeremy Custenborder wrote:
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?
Yes. Just as "bytes" is represented in Java by java.nio.ByteBuffer,
"org.apache.avro.lib.Date" could be represented by java.util.Date.
Does the serializer handle a date object that is
native to the language?
Yes, serializers and deserializers would need to implement this mapping.
Does this sound like a reasonable approach?
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.
> Add Date/Time data types
> ------------------------
>
> Key: AVRO-739
> URL: https://issues.apache.org/jira/browse/AVRO-739
> Project: Avro
> Issue Type: New Feature
> Components: spec
> Reporter: Jeff Hammerbacher
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
