@Elise R: Looks like setting useUTC to false places the labels on the expected time: http://jsfiddle.net/highcharts/y6Q7p/31/

Thanks for including this; it's great for detailed consistency.

I have an issue, though - when a timezone offset is applied, as in your first demo case, but the time is zoomed out to span several months, the ticks are labeled with the wrong month.

To illustrate, just change the pointInterval in your demo (http://jsfiddle.net/highcharts/y6Q7p/) to 2678400000 (one month). The first data point should be on January 1, but the tick beneath it is labeled December. The problem persists when the pointInterval is changed to 32140800000 (roughly one year) - the first data point is plotted as being in 2012 instead of 2013, as it should be.

Is there a workaround I'm missing? Thanks!

Thanks for the good work on this.

I opened a new request: Support timezone as a geographical concept (e.g. "America/New_York") not a fixed offset (e.g. 300 minutes)

https://highcharts.uservoice.com/forums/55896-general/suggestions/6033580-support-timezone-as-a-geographical-concept-e-g

Please cast your vote there! Thanks!

@Nick H: I appreciate the idea, I suggest you open up a separate request for it since this one is completed.

@Jeff: I believe Nick is just asking for a convenient hook, so that he can plug in 3rd party libraries that specifically deal with this kind of stuff.

Time zone offsets are almost never a consistent number of seconds. Implementing this as such will not correctly handle daylight savings time or changes in time zone definitions. That is the reason this sort of thing is so difficult to do in JavaScript, because JavaScript does not provide any functionality to convert between arbitrary time zones using real time zone definitions.

Have been using the global.timezoneOffset feature since it's release thanks, however this is a new request based on the original...ie. global.timezoneOffset should also allow a user defined function which can dynamically specify the timezoneOffset to be used based on the specific datapoint/axis tick being rendered. then users would be able to use 3rd party libraries such as momentjs-timezone, etc. to determine what utc offset to use for a particular timestamp being rendered. ie. DST support in any timezone rather than always applying a static offset.

Timezones are easily applied as long as you know the number of minutes to offset. DST however is not that easy, as it implies two different timezone offsets are applied to the same data.

Is there any plans for adding timezone support? ie. being able to use moment-timezone or similar lib so that data can be displayed in a selected timezone with dst support. ideally global.timezoneOffset could be specified as a function which receives a timestamp and can then dynamically calculate the applicable offset.

I agree with Magnus Lüttkens about the need for time-zone region support. (E.g. America/New_York). Without that DST can't be handled.

Perhaps let us plug in a function that takes a JS Date long and returns an offset for that. Then we could use momentJs or something to solve the problem.

We will probably start preparing a new maintenance release very soon, we I would say within a few weeks.

The new timezoneOffset feature comes very handy. When should we expect the official release of highstock.js with the timezone support ? Thanks.

For my purposes, a perfect solution would be if the time would just display 'as-is'.
i.e no timezone applied. Of course in this case the format given would have to be: YYYY-MM-DD hh:mm:ss
(potentially a .millisec at the end)
This would completely eliminate issues with "data not matching the output" type of problems on time axis.

This is broken because your offset can change mid dataset because of daylight savings time. You should accept moment datetime objects as well as strings and you could possibly solve the problem.

If you want fancy timezone support than use library like Moment.js: http://momentjs.com/timezone/

I do not believe this should go into visualization library.

@Mark: For consistency we follow the ECMAScript definition of timezoneOffset, as used in the Date.getTimezoneOffset method. It is negative for eastern hemisphere and positive for western: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTimezoneOffset

@Ilya: Sorry for the inconvenience, I updated the link now.

@Magnus: As you say, this will add a lot of code that I am not sure belongs in a data visualization library like this, so for now we stick to the offset in minutes. However it would be convenient to add a JSON file with the conversion between time zone names and values.

Timezone offset is definitely a good feature, but I would like a feature where you can set the timezone in Olson format (http://en.wikipedia.org/wiki/Tz_database), such as "Europe/Stockolm", so that DST is handled as well. I understand this is a lot more complex since you will have to build a table with DST-transition dates for each timezone. But it would be great!

The highstock.js link above isn't working...

Shouldn't the timezone offset be positive for the Eastern hemisphere and negative for Western?

+1. Until this gets added to a new version of Highcharts we have implemented a workaround using a different xAxis-Formatter. All dates coming from your API should be in UTC timezone, and the formatter will take care of displaying the correct timezone. Have a look at this gist to get a starting point for your own implementations: https://gist.github.com/j0nes2k/7316272

has this been resolved yet?