I think precision is a big issue for a timestamp type. I found an article to discuss this issue across languages: https://nickb.dev/blog/iso8601-and-nanosecond-precision-across-languages/
In our own experience, we just typedef i64 to TimestampMilliseconds for milliseconds precision (example <https://github.com/reddit/baseplate.py/blob/94b2fc3616c912cc558800e023be10968b41c104/baseplate/thrift/baseplate.thrift#L8>) and that's good enough for most of our cases. If someone needs a higher precision than milliseconds, they can just typedef another one. An ISO-8601 timestamp type, in comparison, will infer much bigger overhead when converting to/from string, and with hugely increased complicity to deal with the variations of the string, and with no guarantee that the precision represented in the string will be preserved in the language library. So overall I don't think an ISO-8601 timestamp type is a good idea. A ISO-8601 date time might be ok, but its usage is much smaller compared to timestamps, and I'm not sure if it's worth the effort. On Sat, Jun 4, 2022 at 8:46 AM Liu Jiayu <[email protected]> wrote: > 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? > > > > >
