Setting in what timezone dateTimeLabelFormats are displayed. There is already useUTC, but usually when you have market data the time zone is displayed as the time zone of that specific market. So if someone is in for example in italy looking at data from Brazil, it's suppose to see the time as in BRST (Brazilian standart time) and not the local time zone setted in their computer
Implemented this option today. The new option, global.timezoneOffset, should be used when useUTC is true to change how dates are displayed and grouped on axes, data grouping and labels/tooltips etc. Please test the new feature with your own data and report back in this thread.
The Highstock file can be loaded from http://github.highcharts.com/highstock.js.
Martin Eismann commented
+1 My company need this to monitor live data in the user's time zone whatever the browsers local time is.
Ivan Di Giusto commented
It would be of great help to feed data in unix epoch time (UTC timezone) then choose the time zone to display, regardless of the browser time.
Any serious international business showing data will have this issue. Please raise the profile of this feature.
Andy Byrne commented
This would be fantastic to have implemented. Currently working on a project that needs this exact feature.
Sebastian Gingter commented
+1, that would come in very handy here too
Greg Wood commented
This would be extremely useful for a project we are currently working on. We need to support user selectable timezones, and at the moment are looking at writing a wrapper to Highcharts to feed it "adjusted" times.
+1. In it's most simple form all we need is an 'Offset' option+setter which can be applied by the chart on series render. eg. series.timeOffset: "-13:00" (alternatively in mins or ms). Actually it will probably have to be applied in global settings.
Major benefit: series can be re-rendered with any offset applied without having to reload the data from the server (as with the offset workaround). Typical scenario: client-side web app with timezone setting saved in user profile. series have been rendered and user changes their profile timezone setting. The expected outcome is that the charts re-adjust their x axis to account for the new timezone offset. At the moment it means either another trip to the server or a lot of additional client-side processing (re-offsetting all the timestamps in the complete dataset(s)). Even with the client-side processing option it means having to cache the data on the client...and there can be a lot of data.
Henrik Schiznel commented
+1. This is an essential feature for us. We are working on a solution along the line of the suggested workaround. But this causes confusing code as the code states that the time is UTC when it is not. This will confuse and have to be explained to every developer that will work with this code. Sooner or later this will cause problems.
try the support forum - http://highslide.com/forum/viewforum.php?f=9
Tom Hansen commented
The proposed workaround would not work -- I do not believe -- if the date range displayed spans a change from daylight time to standard time, or vice versa, because you would either see a gap in the data or overlapping values. If data were strictly ordinal, perhaps it could work, but if not, it would probably not work.
Jason Petersen commented
A JSON API is a JSON API and it needs to return the right data. Having it lie about the data to get Highcharts to display it correctly is not always an option.
Magnus Lüttkens commented
This is also an important feature for us. We're displaying energy consumption patterns over time, so timezone has to be where the consumption takes place, not where the browser is.
I need this also - +1. Thank you!
This would certainly be useful for a project I'm working on. I would have thought there are many cases where a time zone adjustment would be useful.
Denis Bohm commented
This is also useful for other charts (not just market data). In my case I'm using Highcharts to display administrative data for users from all over the globe and the data needs to be shown using the users time zone, not the time zone of the administrators browser.