bokeh: [BUG] DateRangeSlider is broken

ALL software version info (bokeh, python, notebook, OS, browser, any other relevant packages)

Bokeh 2.0.0dev6 (ff2d2f62)

Description of expected behavior and the observed behavior

If start is set to today, the slider is not displayed at all. The JS exception:

Error rendering Bokeh items: TypeError: Cannot read property '0' of null
    at nouislider.js:298
    at Array.sort (<anonymous>)
    at new Spectrum (nouislider.js:298)
    at Object.testRange [as t] (nouislider.js:392)
    at nouislider.js:711
    at Array.forEach (<anonymous>)
    at testOptions (nouislider.js:703)
    at Object.initialize [as create] (nouislider.js:1770)
    at DateRangeSliderView.render (abstract_slider.js:105)
    at DateRangeSliderView.build (layout_dom.js:119)

It’s caused by the start value being null on the JS side. The relevant attributes value in the PULL-DOC-REPLY message:

{end: 1583107200000, value: ["2020-02-21", "2020-03-02"]}

If start is set to any other day, the slider is displayed, but incorrectly - it doesn’t depict the actual range. There’s only one handle at the very start. Any attempt to move it leads to the displayed value set to

function () { return request.convert(arguments); } .. function () { return request.convert(arguments); }

and the exception:

ValueError: expected an element of Tuple(Datetime, Datetime), got (None, None)

It’s caused by an incorrect update to the value field. One of the corresponding WS messages:

{"events":[{"kind":"ModelChanged","model":{"id":"1041"},"attr":"value","new":[null,null]}],"references":[]}

Complete, minimal, self-contained example code that reproduces the issue

from datetime import date, timedelta

from bokeh.io import curdoc
from bokeh.models import DateRangeSlider

start = date.today() - timedelta(days=1)
end = start + timedelta(days=10)
beginning = DateRangeSlider(value=(start, end), start=start, end=end)

curdoc().add_root(beginning)

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 25 (25 by maintainers)

Most upvoted comments

Sure, FYI we try to be tz-naive i.e. treat all datetime values as local and leave it to users to convert as necessary for what they want to show. The issue with the old date picker was that we could not prevent a conversion that it did internally which really mucked with that assumption.