I still believe: using the convention used by Arrow, i.e., adding date32 and date64, where date32 for number of days past since UNIX epoch, and date64 for number of milliseconds past since UNIX epoch, can be useful without introducing ambiguity; for formatting using ISO 8601, users can still fallback to string, for passing nanoseconds, users can still leverage typedef of i64, etc.
If we have date32 and date64, the generator can generate unambiguous and idiomatic types within major languages, for example, in Java, date32 maps from [1] and to [2] LocalDate, and date64 maps from [3] and to [4] Instant. [1]: https://docs.oracle.com/javase/8/docs/api/java/time/LocalDate.html#toEpochDay-- [2]: https://docs.oracle.com/javase/8/docs/api/java/time/LocalDate.html#ofEpochDay- long- [3]: https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html#toEpochMilli-- [4]: https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html#ofEpochMilli- long- On June 5, 2022, Jens Geyer <[email protected]> wrote: > That being said, I would happily support it if we settle on an > agreement. Would be a good thing. > > > Am 04.06.2022 um 12:39 schrieb Jens Geyer: > > > > 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? > >
