Thanks to everyone who voted and/or provided feedback! The vote passed with 4 binding +1s (Gwen, Grant, Jason, Becket) and 5 non-binding +1s (Matthias, Vahid, Bill, Dong, Mickael).
El mié., 5 abr. 2017 a las 11:58, Jorge Esteban Quilcate Otoya (< quilcate.jo...@gmail.com>) escribió: > Thanks Ismael! Response inline. > > El mar., 4 abr. 2017 a las 17:43, Ismael Juma (<ism...@juma.me.uk>) > escribió: > > Sorry for the delay Jorge. Responses inline. > > On Thu, Mar 23, 2017 at 5:56 PM, Jorge Esteban Quilcate Otoya < > quilcate.jo...@gmail.com> wrote: > > > @Ismael, thanks for your feedback! > > 1. Good point. I will add optional support for timezone as part of the > > datetime input. But, when datetime is without timezone, would it be more > > consistent to get the timezone from the cluster first and then reset > based > > on that value? Not sure if it is possible to get that info from the > > cluster. But, in case that's not available, I could add a note to advise > > that in case timezone is not specified the tool will get that value from > > the client and it would be user's responsibility to validate that is > > aligned with the server. > > > > There's no way to get such data from the Cluster today. It's relatively > common for servers to use UTC as their timezone though. Is there any value > in using the client timezone? Today's apps typically have data from all > over and what are the chances that the time zone from where the client is > running is the correct one? > > > You're right, make sense to use UTC by default and accept Timezone as part > of the input value. I updated the KIP. > > > > > 2. Happy to add it to the KIP. > > > > OK. > > > > 3. This was part of the discussion thread, we end up with `shift-by` to > > avoid adding `offset` to each case and make it a bit more consistent. > > > > OK. > > > > 4. I could remove CURRENT-OFFSET and CURRENT-LAG from the output, and > leave > > it as part of `describe` operation, if that's better. > > > > It seems better to me as one would hope people would look at describe to > find the current values. > > Done, KIP updated. > > > > 5. Agree. At the beginning we consider `shift-plus` and `shift-minus`, > but > > agree to join them in one option and accept +/- as input. Maybe that's a > > better option? > > > > Not sure, maybe it's fine as it is. I can't think of anything better, at > least. > > > Agreed, I also think is good enough as it is now. > > > > Ismael > > > Jorge. > >
