thank you for the detailed context - i didn't know about the past discussion and i can totally relate to the fact that it's a complex topic.
coming from apache arrow, i've come to know its design choices (date32/64) - it's not perfect but i guess worth looking at, given it's also a cross-language protocol with careful design on memory layout and processing efficiency. https://arrow.apache.org/docs/format/CDataInterface.html For date32 it stores in a 4 byte area the number of seconds past UNIX epoch, and for date64 it stores in a 8 byte area the number of milliseconds past UNIX epoch. To me that sounds like a good standard across all languages. On 2022/06/04 10:39:32 Jens Geyer wrote: > > jiayuliu wrote: > > Taking a step back, I wonder if we can standardize on a paved path > > for adding newer standalone types in terms of requiredness/optional, > > plugin mechanism, and/or the level of language support, e.g. if I > > want to add support for date/time/timestamp, following ISO 8601, > > [https://en.wikipedia.org/wiki/ISO_8601,] is that necessarily a > > good idea to be a standalone type? > > Date and timestamps are a good topic a s well, although also a more > complicated one. We discussed that shortly in the past (years ago I > might add) and came to thne conclusion that because of the sheer > plethora of different systems w/regard what systems expect to be a good > date/time format onm the market it is quite hartd to come to one way > that satisfies all sides: > > Main thgings to consider: > > * what is the offset? i.e. what is date null? > * what is the precision to store? > * is there a (good) way to handle it available for each language? > > I'm personally would be thankful if we have some good timestamp data > type, but I also see the problems with it. > > JensG > > PS: What you mean by "in terms of requiredness/optional"? How is that > related? > >
