Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Datetimes on plot are always treated as local time and shifted to UTC #5499
For example, if you live in UTC-05:00, then all the dates are shifted ahead 5 hours (7am appears at noon).
This happens regardless of the
I would have expected that naive datetimes are displayed as is.
System, Library, Browser, Version information
I am using Python 3.5.2 (64-bit) with bokeh 0.12.3 and Firefox 50.0 as well as Chrome 54.0.2840.100 (64-bit) on Ubuntu MATE 16.04.1 LTS and on CentOS release 6.8.
bokeh info (Ubuntu):
bokeh info (CentOS):
You can work around this issue by setting your system timezone to UTC. This is not ideal though.
Does anyone with more insight into Bokeh/BokehJS's handling of datetimes than myself have any idea what might be responsible? From what I gather we should expect datetimes to be displayed as-is so am I right in guessing that Bokeh does not have any timezone handling implemented? In which case we could expect the issue to be on the client side or during serialization?
For reference, the BokehJS
This makes use of the JS
Maybe there is a misuse of
As a first experiment, can you print out the actual timestamp values from the column data source in the hover tool? Then round trip them to human readable. If they match what you passed in to start this will confirm the issues is purely on the JS side.
@mwerezak sorry, What I meant was to compare the timestamps in the in the hover tool (from the column in the BokehJS data source) to the original python timestamps, and by "human readable" I just meant it might be easier to compare the values if you use one of the many datetime functions for turning timestamps into something more friendly for humans to understand. What I am trying to get at: are the timestamp in the data source correct (i.e. they match the python original data), and just the presentation/view of them is wrong? Or are the actual timestamps in the data source changed/incorrect?
@bryevdv does this resemble what you were looking for at all?
I did notice a factor of 10^3 discrepancy at first, which is likely due to what you mentioned in your last comment. After applying the corrective factor, there does still seem to be a small difference, however it is very small, and certainly would not account for a 5 hour shift.
@mwerezak OK thanks, that is useful information. I believe then perhaps the issue is purely with our usage of
Just to complete things, can you confirm the axis tick value "16hr" does correspond to the correct hour in the original python data for that point?
referenced this issue
May 11, 2017
Based on some observations in #6278 I no longer think this is a BokehJS or purely display issue. Rather, we convert datetimes like this:
But the help for
I believe this might be where unintended introduction of local time interpretation is inserted.
Well, maybe not, but there is something weird going on, and I don't understand it.
NumPy datetime64 are converted like this:
Datetimes were converted like this:
So I tried this instead, to avoid the use of
But that ALSO gives
Which one of these answers should be considered correct? AFAIK the numpy value is UTC and I think that is what we intend.
FYI my local timezone is CST
Anyone have ideas here? This is not my area of expertise.
OK, this matches the NumPy computation:
Question then: Is this the correct thing to do??
I believe so. I get the same, tz-independent value as you if I do (i'm in ART):
>> d = dt.datetime(2016, 5, 11) >> epoch = dt.datetime.utcfromtimestamp(0) >> (d - epoch).total_seconds() * 1000 + d.microsecond / 1000. 1462924800000.0
I get a different value using mktime.
OK so I am proposing this snippet for the
With that implementation, all the following agree on my machine: