Skip to content
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

hover.tooltip convenience function for 'datetime' info #1239

ijstokes opened this issue Sep 23, 2014 · 21 comments

hover.tooltip convenience function for 'datetime' info #1239

ijstokes opened this issue Sep 23, 2014 · 21 comments


Copy link

@ijstokes ijstokes commented Sep 23, 2014

It would be nice to make it easy to create a "hover" tooltip template that could do some simple conversions/formatting on "standard" data point information: x, y, size, color, etc. Maybe also some convenience conversions for source attributes of data points.

My particular scenario has to do with providing a hover tooltip which displays a human-readable time stamp for the data point. The x-axis is configured as datetime, but when I display $x I get back a float (seconds since the epoch) which isn't very readable. To get around this, I need to add a ColumnDataSource with a single field, like so:

source = ColumnDataSource(data=dict( x: x.strftime('%d-%m-%Y'))

and then I tell my tooltip to display ("time", "@time"). This is workable, but it would be nicer if I could just do:

("time", "`stftime('%m-%d-%Y', $x)`"

or something similar to say "do a client-side conversion of $x into something more human-readable"

Copy link

@damianavila damianavila commented Sep 23, 2014

It is a nice idea... I heard a lot of weird and funny thing with date handling and formatting in the js side... but I suppose we could try...

@damianavila damianavila added this to the long-term milestone Oct 13, 2014
Copy link

@bryevdv bryevdv commented Oct 14, 2014

@damianavila we have a sprintf library on the JS side, we can probably just pass an optional format string directly to it.

@damianavila damianavila modified the milestones: short-term, long-term Oct 14, 2014
Copy link

@mattpap mattpap commented Dec 2, 2014

Preliminary support for number and time formatting was added in PR #1484. Thought, no support for date formatting yet.

Copy link

@drorata drorata commented Feb 27, 2015

This is a great addition! Thanks! Could someone add some snippets explaining how to use this?

I got so far:

hover.tooltips = {"x":"$x{int}", "y":"$y{int}"}

will format the values as integers.

Assuming that x is a timestamp-integer, it would be really nice to be able to format it into a date-time.

Copy link

@steve98654 steve98654 commented Mar 26, 2015

I second this feature request. Including additional formatting options for other datatypes would be nice as well (perhaps use formatting options similar to those that a DataTable has?)

Copy link

@Rakeshbart Rakeshbart commented Apr 7, 2015

Yes this feature would be really helpful as I have many plots with datetime as the x axis. could you please explain how to use this as well.

Copy link

@davideuler davideuler commented May 5, 2015

I create the DataSource for human readable datetime like this, and then pass the datasource to glyphs.

def create_data_source(data_frame):
    return ColumnDataSource(
            date=[x.strftime("%Y-%m-%d") for x in data_frame['date']],

df_inc = df[df.close >]  # get the subset of data frame whose close is bigger than open.
source_inc = create_data_source(df_inc)

p.rect([inc], mids[inc], w, spans[inc], fill_color="#F2583E", line_color="black",source=source_inc)
Copy link

@esvhd esvhd commented Aug 19, 2015

I also support adding this feature, will be very helpful. My hack right now is to create a column of strings representing the dates in my data frame passed in as source and refer to that column in the tooltip..

Copy link

@adriantorrie adriantorrie commented Feb 2, 2016

This feature would be great to have!

Perhaps intially having the ISO 8601 standard covered first with the simple notation of:

  • $x{date-time} -> output: 'YYYY-MM-DD HH:MM:SS.[fractional seconds]'
  • $x{date} -> output: 'YYYY-MM-DD'
  • $x{time} -> output: 'HH:MM:SS.[fractional seconds]'

The actual format of ISO 8601 timestamp has a 'T' or 't' between the date and time parts, e.g ``'YYYY-MM-DDTHH:MM:SS.[fractional seconds]'`, however I've replaced the 'T' with a space character to be human readable. This is acceptable according to RFC3339 in section 5.6 Internet and Date/Time Format:

NOTE: ISO 8601 defines date and time separated by "T".
Applications using this syntax may choose, for the sake of
readability, to specify a full-date and full-time separated by
(say) a space character.

Further examples of international agreed standards are found in RFC3339. Note tough that RFC3339 has the following:

The following is an attempt to create a formal
grammar from ISO 8601. This is informational only and may contain
errors. ISO 8601 remains the authoritative reference.

The above gives a grammar for format names, some examples for discussion are (their are many more in the RFC document above):

  • date-month -> usage: $x{date-month} -> output: 01-12
  • date-mday
  • time-hour
  • time-offset
Copy link

@AlJohri AlJohri commented May 3, 2016

@mattpap you mentioned the preliminary support for number and time formatting is done - how does one use the time formatting? I only got as far as @drorata with "$x{int}"

Copy link

@VelizarVESSELINOV VelizarVESSELINOV commented Jun 1, 2016


Copy link

@Rubyj Rubyj commented Oct 17, 2016

@mattpap @bryevdv Has this functionality been added yet? I have a hover tooltip being outputted as an epoch string when it is a date on the python side.

Copy link

@mattpap mattpap commented Oct 17, 2016

@Rubyj, no, not yet, though this is something we could add fairly easily as we already ship timezone library with bokehjs (used for axis tick label formatting).

Copy link

@ghost ghost commented Feb 8, 2017

So this feature (to format unix timestamp as datetime in the hovertool) is requested since 2+ years, and not yet implemented in the latest bokeh release?

The workaround with adding a separate column to the ColumnDataSource where this info is stored as formatted text string is not appealing to me.

Then, why not using the custom tooltip option? For example, this works for my purpose:

hover = HoverTool(
                <p>time_start: <span id="_time_start"></span><p>
                <p>time_end: <span id="_time_end"></span><p>
            function fun(unix_timestamp) {
                var d1 = new Date(unix_timestamp);
                return d1.toISOString()
            document.getElementById("_time_start").innerHTML = fun(@time_start);
            document.getElementById("_time_end").innerHTML = fun(@time_end);

Still, I would prefer to have a formatting option in the native tooltip feature, e.g. $x{date-time}


Copy link

@bryevdv bryevdv commented Feb 14, 2017

So this feature (to format unix timestamp as datetime in the hovertool) is requested since 2+ years, and not yet implemented in the latest bokeh release?

There is more work to do than is humanly possible accomplish by the number of people currently available to do it. New contributors are always welcome. That is literally the only thing that can cause any improvement in issue resolution times at this point

Copy link

@Corleo Corleo commented Feb 15, 2017

As an improvement suggestion, how about an option to get the own axis formatter to format the hover tooltip so it can be done at the browser side and do the formatting only on part of data that is being displayed in plot?

Copy link

@bryevdv bryevdv commented Apr 13, 2017

I believe this can now fairly easily be accomplished by allowing a "formatter" field in data specs, that accept a Transform. [*] Then the (optional) transform can be used during any display of the data, e.g. by a hover tool. We can provide some canned format transforms such as for date times, but a CustomJSTransform opens up possibilities for users to insert arbitrary transforms.

[*] Or should it be a tick formatter? the functionality certainly matches the use case but the terminology (naming) is off.

Copy link

@bryevdv bryevdv commented Apr 22, 2017

OK, scaling back to something slightly less ambitious. Will push a PR later today that provide for things like this:

p2.add_tools(HoverTool(tooltips=[("date", "@x{%F %T}")], formatters={"x": "datetime"}))

Which yields:

screen shot 2017-04-22 at 13 59 50

So formatters can optionally specify one of "datetime", "printf", or "numeral" for a CDS field name, which will use tz, SPrintf orNumbro respectively when displaying values from that field.

If no formatter is specified, it defaults to Numbro which preserves the current behavior

I think this leaves the door open for custom formatter models in the future, with something like

HoverTool(tooltips=[("date", "@x{custom}")], formatters={"x": my_custom_formatter})

but I don't want to tackle that right now because I don't want to tackle decision about what if anything to do to merge tick formatter and text formatters right now.

Copy link

@sigurdurb sigurdurb commented Apr 23, 2017

warning and thx to @artur-scholz "to ISO string" method.
It works but it needs to add the {0.0000} formatting for the incoming unix date like so:

 document.getElementById("_time_start").innerHTML = fun(@time_start{0.00000000});
 document.getElementById("_time_end").innerHTML = fun(@time_end{0.00000000});

I just got the first letters of some unix date rounded to the fourth number like 1493000000000 when I should have got 149291492944633005.431


This comment has been hidden.

Copy link

@karlglazebrook karlglazebrook commented Jul 22, 2020

I think this leaves the door open for custom formatter models in the future, with something like

HoverTool(tooltips=[("date", "@x{custom}")], formatters={"x": my_custom_formatter})

This is nice and I found it in a google search on how to do this. Thanks!

But I was wondering - is the use of "@x" (as opposed to "$x") documented anyway? I searched the docs and couldn't find it. It seems to give the actual point value as opposed to "the data value nearby where the mouse is." I get the impression that @x and @y are provided as some kind of default ColumnDataSource.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.