@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. 2. Happy to add it to the KIP. 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. 4. I could remove CURRENT-OFFSET and CURRENT-LAG from the output, and leave it as part of `describe` operation, if that's better. 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?
El jue., 23 mar. 2017 a las 17:17, Ismael Juma (<ism...@juma.me.uk>) escribió: Hi Jorge, Thanks for the detailed KIP. The tool looks very useful. A few comments: 1. We are using the default timezone of the client for the specified date. This seems a bit error prone. Would it be better to require the users to specify the time zone as part of the date time? We should at least allow it, but my experience when it comes to using the default time zone in a distributed environment is not great. 2. It seems like we are using the ISO 8601 format for date time and duration. It would be good to mention that. 3. `shift-by` should perhaps be `shift-offset-by` to be a bit clearer. 4. Printing the current offset via reset-offsets is a bit odd, can we not use a different option for that? 5. It's a bit odd that `by-duration` subtracts while `shift-by` moves forward. It would be nice if the name made it clear that `by-duration` is subtracting, but I have no good suggestions, so maybe that's the best we can do. Ismael On Fri, Feb 24, 2017 at 12:46 AM, Jorge Esteban Quilcate Otoya < quilcate.jo...@gmail.com> wrote: > Hi All, > > It seems that there is no further concern with the KIP-122. > At this point we would like to start the voting process. > > The KIP can be found here: > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > 122%3A+Add+Reset+Consumer+Group+Offsets+tooling > > > Thanks! > > Jorge. >
