I am in the UK where it's currently daylight saving time (BST = UTC + 1).
If I pass a series of data to the line chart using timestamps, the chart shows 1 hour later than the timestamp.
Is this the expected behaviour?
My real code is trying to display weather forecast data for Colombo, which is currently 5.5 hours ahead of UTC, 4.5 hours ahead of BST. I may want to view it on a browser in Rio de Janeiro, currently 3 hours behind UTC, but wherever it's viewed it should show the times correct for Colombo.
Here is an example, sending data timestamped 12:00, 15:00 and 18:00 :
temps=;
temps= [
{"x": 1537790400000, "y": 10}, //1537790400 is 2018/09/24 12:00 UTC
{"x": 1537801200000, "y": 10}, //1537801200 is 2018/09/24 15:00 UTC
{"x": 1537812000000, "y": 10}]; //1537812000 is 2018/09/24 18:00 UTC
Yes, this is the expected behavior... all internal timestamps should be in UTC time, which is converted to localtime upon display. The output display time follows the timezone of the browser that is showing the charts. In your case, that appears 1 hour later than UTC -- if you viewed the same data from a browser in Rio, the times should appear 3 hours behind UTC.
In your example data, the first timestamp is 2018/09/24 12:00 UTC -- so it appears that you have already converted the temp forecase (in Colombo?) to universal time. Is that correct? Or was that temperature forecasted for noon localtime in Colombo?
Thanks for the reply.
No the data in my enquiry was just made up to illustrate the problem. And I only use Colombo for development because their timezone offset isn't an integer.
Real data would be a mixture of the past ("current conditions" - maybe 3 hours old) and future (forecasts)
And real data (OpenWeatherMap.org) has Unix timestamps.
So to chart timestamped data for a different timezone I have to:
Subtract the site visitor's timezone offset as milliseconds.
Add the forecast location's timezone offset as milliseconds.
The timezone of the computer that hosts the flow is irrelevant...
I'm waiting for a friend in Rio to check the page for Colombo to see if I have it working right.
But it isn't going to be correct if the chart spans the time when daylight savings time starts or ends.
Since you are getting the data from a service that provides all timestamps as UTC, the UI would have to know which timezone to display, and adjust the "presentation" of the data accordingly. Normally, the browser's timezone would be used to determine that, and indeed the current dashboard widgets use that as its default behavior.
In your case, you are right that the timezone of the node-red server is irrelevant -- and it seems the same is true for the clients. So whoever is looking at the graph is free to choose which "location" to show, and they would expect all times to be shown in that location's timezone?
Assuming that's correct, I strongly suggest you not try to fiddle with adding and subtracting timezone offsets. As you correctly assessed, that logic will have problems when DST starts and ends (and other times as well). Instead, I think that your best bet would be to retrieve the UTC data, and pass it through a node-red-contrib-moment node that is configured to convert from the current browser's timezone to that target location's timezone (or perhaps I have that reversed). The net effect is to trick the local chart UI to show the desired location's forecast.
If you need more help with how to actually apply the moment node conversions to an array of timestamped readings, or to format the data for viewing in the chart, please include some sample data and the part of the flow that processes the data and shows the chart... Good luck!
That does look like a limitation of the moment node, right now. So if you have a finite set of target timezones, you would just need that many pre-configured moment nodes, and a switch to direct them to the right one.
