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.
