You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a meta-issue on the handling of datetime widgets across Lumen, Panel and Param. I'm posting it here as the goal of this analysis was to see what were the missing parts to update the date/datetime filters offered by Lumen. But of course this entails improving Panel, and in some cases improving Param (as was done recently with improving the serialization support, to allow syncing a date filter value with the URL).
For now, this skips mentioning time zones, which is another analysis of its own.
Python
First useful observation, datetime.datetime is a subclass of datetime.date.
Param 1.12.2
Date Parameters and the types they accept
Given the type alias dt_types as datetime.date | datetime.datetime | np.datetime64.
CalendarDate: datetime.date and not datetime.datetime
DatetimeRangeSlider is new and inherits all from DateRangeSlider except that it is based on another Bokeh widget that renders the values as datetimes. DateRangeSlider's value Parameter should be CalendarDate
DateSlider has a as_datetime Boolean Parameter that when True leas to value being casted to datetime.date or datetime.datetime.
Missing DatetimeSlider whose display is a datetime:
Missing DateRangePicker whose value Parameter is a CalendarDateRange. There's actually an open PR by a contributor: Daterangepicker panel#2804
Missing a DateInput widget whose value Parameter is a CalendarDate and displays as a calendar date
DatetimeRangeInput won't serialize as the Parameter that holds the datetime values isn't a date-like Parameter but a bare tuple.
Lumen
Current Date Filters
Lumen currently has one date filter -DateFilter - whose behavior can be changed by setting the mode parameter:
slider: DateRangeSlider
picker: DatePicker
Observations/Suggestions
More date filters should be made available to Lumen users!
Add datetime filters as there's currently none.
WidgetFilterand BinFilter both have a multi parameter, multi=True meaning that a multi-select widget is used instead of a single-select widget. As far as possible this distinction should be reused to keep the
Suggested changes to DateFilter:
Mostly by adding a multi parameter that is True by default asmulti is True by default for WidgetFilter and BinFilter. mode being currently 'slider' by default this also preserves the current default widget users get by declaring a DateFilter. However, when mode is set to 'picker' the proposed logic would lead to a DateRangePicker, that doesn't yet exist. There are three options:
add the DateRangePicker to Panel before its next release and the next release of Lumen
temporarily return a DatetimeRangePicker, and make sure that the date types are correctly handled
temporarily return anyway a DatePicker, to totally preserve backwards compatibility, raising a warning that this should change in a future version in favor of a DateRangePicker. We may have to bend the code in a weird way for this to work, as a DatePicker isn't a multi type of widget
I'd go for 1, or 2, but not 3 as I've got access to a code base with many Lumen apps where I saw no usage at all of the 'picker' mode.
multi
mode
Panel widget
True
slider
DateRangeSlider
True
picker
1, 2 or 3?
False
slider
DateSlider
False
picker
DatePicker
Suggesting adding a new DatetimeFilter:
multi
mode
Panel widget
True
slider
DatetimeRangeSlider
True
picker
DatetimeRangePicker
False
slider
fallback to DatetimePicker
False
picker
DatetimePicker
As there's no DatetimeSlider I would just document that this isn't yet a supported case, emit a warning and fall back to a DatetimePicker.
The text was updated successfully, but these errors were encountered:
This is a meta-issue on the handling of datetime widgets across Lumen, Panel and Param. I'm posting it here as the goal of this analysis was to see what were the missing parts to update the date/datetime filters offered by Lumen. But of course this entails improving Panel, and in some cases improving Param (as was done recently with improving the serialization support, to allow syncing a date filter value with the URL).
For now, this skips mentioning time zones, which is another analysis of its own.
Python
First useful observation,
datetime.datetime
is a subclass ofdatetime.date
.Param 1.12.2
Date Parameters and the types they accept
Given the type alias
dt_types
asdatetime.date | datetime.datetime | np.datetime64
.datetime.date
and notdatetime.datetime
dt_types
Tuple[datetime.date, datetime.date]
Tuple[dt_types, dt_types]
Observations/Suggestions
CalendarDateRange
actually accepts a tuple that contain one or moredatetime.datetime
values. Not sure how disruptive it would be to change that.Panel 0.13.1
Date Widgets
Observations/Suggestions
DatetimeRangeSlider
is new and inherits all fromDateRangeSlider
except that it is based on another Bokeh widget that renders the values as datetimes.DateRangeSlider
'svalue
Parameter should beCalendarDate
DateSlider
has aas_datetime
Boolean Parameter that whenTrue
leas tovalue
being casted todatetime.date
ordatetime.datetime
.DatetimeSlider
whose display is a datetime:type
argument.DateRangePicker
whosevalue
Parameter is aCalendarDateRange
. There's actually an open PR by a contributor: Daterangepicker panel#2804DateInput
widget whosevalue
Parameter is aCalendarDate
and displays as a calendar dateDatetimeRangeInput
won't serialize as the Parameter that holds the datetime values isn't a date-like Parameter but a bare tuple.Lumen
Current Date Filters
Lumen currently has one date filter -
DateFilter
- whose behavior can be changed by setting themode
parameter:slider
:DateRangeSlider
picker
:DatePicker
Observations/Suggestions
WidgetFilter
andBinFilter
both have amulti
parameter,multi=True
meaning that a multi-select widget is used instead of a single-select widget. As far as possible this distinction should be reused to keep theSuggested changes to
DateFilter
:Mostly by adding a
multi
parameter that isTrue
by default asmulti
isTrue
by default forWidgetFilter
andBinFilter
.mode
being currently'slider'
by default this also preserves the current default widget users get by declaring aDateFilter
. However, whenmode
is set to'picker'
the proposed logic would lead to aDateRangePicker
, that doesn't yet exist. There are three options:DateRangePicker
to Panel before its next release and the next release of LumenDatetimeRangePicker
, and make sure that the date types are correctly handledDatePicker
, to totally preserve backwards compatibility, raising a warning that this should change in a future version in favor of aDateRangePicker
. We may have to bend the code in a weird way for this to work, as aDatePicker
isn't a multi type of widgetI'd go for 1, or 2, but not 3 as I've got access to a code base with many Lumen apps where I saw no usage at all of the
'picker'
mode.Suggesting adding a new
DatetimeFilter
:As there's no
DatetimeSlider
I would just document that this isn't yet a supported case, emit a warning and fall back to aDatetimePicker
.The text was updated successfully, but these errors were encountered: