On Mon, Jun 6, 2022 at 5:36 AM <[email protected]> wrote: > IMO, supporting even a poor standard is still better than supporting > none at all. > > Datetime handling is indeed a nuanced topic. But consider: how much of > the complexity should fall onto application code VS how much onto a > framework like Thrift? > > As a cross-language RPC, Thrift should focus on interoperable data > transport. With datetimes, that excludes any sort of processing from > the scope: no timezone conversions, no (re)setting of epoch (null > point), no leap seconds, no resolution rounding, no localization. In an > RPC framework, all of that is unwanted extra. It belongs to > applications. The job of the framework is transport of data (e.g. > datetimes) from language A to language B. >
This is exactly why the precision in datetime is such a big issue. Since the job of thrift is "to transport of data (timestamp) from A to B", it needs to preserve the max precision possible, and leave it to the application to decide if they actually need to round it to a lower resolution. That's the max precision possible for a timestamp? That's certainly not milliseconds. Currently it's _probably_ nanoseconds, but that can also change in the future. Which IMHO makes it a poor decision for thrift to make to say "milliseconds is the best precision we can provide for datetime". A precision agreed between both ends of the transport, in a case-by-case basis, is good enough as typedef an i64 is trivial. Back to Jiayu's proposal of date64 provides milliseconds precision and date32 provides day precision: that sounds like a very big surprise to me from the name of the types. It would be so much better to include the unit in the name of the types. > > And when it comes to interoperability -- following standards is king. > Why adding UUID support, doesn't bytearray support suffice?.. Yes it > does not suffice. Noone likes to emulate such a basic feature by > transporting uuids in bytearrays; entailing the complexity cost of > conversion boilerplate (potentially, written out in N languages) and > expanding bug surface. > > Same with datetimes. > > Max @ulidtko > > On Sat, Jun 4 2022 at 12:39:32 PM +0200, Jens Geyer <[email protected]> > 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? > > > > >
