-
-
Notifications
You must be signed in to change notification settings - Fork 536
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
Daterangepicker #2804
Daterangepicker #2804
Conversation
@samuelyeewl Do you still want to add this? I think it's reasonable to add although we might consider making |
Yes, I think it would be useful to have a widget that returns a datetime.date rather than datetime.datetime object (DatetimeRangePicker already has a disable_time parameter, but still returns a datetime with time = 12:00, which can lead to inconsistencies). |
I haven't looked at the details here, but if you are trying to make a parameter not appear and not be used in a subclass, you can redefine it with the same type but a negative precedence and readonly=True (e.g. |
That seems like a weird approach honestly, you should instead create a baseclass that has the parameters you do want to be shared and then subclass from that. |
Or in this case it might be reasonable to invert the hierarchy and have DatetimeRangePicker inherit from your DateRangePicker. |
Good point; that's the right long-term approach. My answer only applies if you are unwilling or unable to do a refactor like that. |
I need this to to support |
Closes #5844 |
Superseded by #6027 |
I added a DateRangePicker widget, for when you only want a datetime.date range rather than a datetime.datetime range.