-
Notifications
You must be signed in to change notification settings - Fork 357
Add support for time.Time flags #348
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This is exactly what I am looking for. Would it be possible to review and merge this? Maybe also suggestion for small improvement, would it be possible to offer some reasonable standard default ordering?
or this:
|
I was thinking of adding a constant slice with a suggested default time format set, but opted to not include it in this PR since its easy to define such a constant in whatever code you use and more importantly I wanted to avoid any long winded discussions on what the actual order and included formats should be. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! Can't wait to get this out and into Cobra.
@johnSchnake tagging you (a bit late) for this PR as requested in spf13/cobra#742 |
This PR implements support for `time.Time` flags which can be used to accept timestamps as input directly (see spf13/cobra#742). The implementation allows defining a list of acceptable timestamp formats which are tested in order, i.e., devs using this flag type would be responsible for ordering their formats correctly should there be an overlap. Merge spf13#348
hate being that guy...but: any news on when will this be in? |
Yeah sadly seems that the repo is just sitting here now anymore nothing happening :/ i tried to make some noise in the related issue on the cobra side but nothing yet |
Anything needed from the community side to cross the finish line with this PR? Happy to test, review, anything... it is a bit of a shame that the de-facto standard CLI library doesn't have a |
Good to see this has been approved... Can it be merged? |
@Kapparina i wish it was this easy :( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me.
Anyone knows who needs to be chased for the approved PR to be merged in this repo? Is it only @spf13 or do more people have merge rights? |
@tomasaschan Sorry for the direct ping, but going by recent activity you seem to have the ability to review and approve PRs. Any chance you'd have some time to look at this 🙇 |
time_test.go
Outdated
devnull, _ := os.Open(os.DevNull) | ||
os.Stderr = devnull |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this needed? What in this test would otherwise write to stderr?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this one going back by memory I believe only reason I've added it was because of copy paste from the test file I modified to make it easier to stick to the repo style.
That is one of these
I've checked now and as far as I can tell non of the occurrences of this in the repo are doing anything.
Removed it for time_test.go in d15848d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the quick response to the review request 🙇
time_test.go
Outdated
testCases := []struct { | ||
input string | ||
success bool | ||
expected string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: I think I'd prefer if this was a time.Time
rather than a string, to make it easier to add other test cases without having to dig into how comparisons are done and what format to specify dates in. But I'm not going to block on that :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in c5ce22e
7e4fa0a
to
1992c5a
Compare
Note during rebase to master I had to rename |
What a coincidence, I stumbled upon this issue earlier today as I was interested in this feature and it seems like this is nearing completion! Fantastic! Thank you Frank for staying persistent on this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of more nits; I added suggestions for them so I can commit them with you as co-author and get this merged, I hope you don't mind :)
e8e90db
to
e3be2eb
Compare
Thanks for your contribution! |
Yeah no worries I am happy to have this modified to fit the new direction 👍 Thanks for the quick support and review after the ping 🙇 |
This PR implements support for
time.Time
flags which can be used to accept timestamps as input directly (see spf13/cobra#742).The implementation allows defining a list of acceptable timestamp formats which are tested in order, i.e., devs using this flag type would be responsible for ordering their formats correctly should there be an overlap.