Ah - so I’ve done a bit more testing. My earlier post is a bit wrong in what triggers the issue, as I thought I had found a workaround only to break something again.
I can get it to reliably fail in the same way as I mentioned in the above post by:
Creating a Virtual Feed - Daily (this doesn’t happen with a ‘realtime’ virtual feed)
Editing that Virtual Feed’s Process list to include a ‘Source Feed’
Simply removing the ‘Source Feed’ From the process list fixes the issue. (or deleting the feed, etc).
I’ve tried this with source feeds that are of the type ‘Realtime PHPFina’ and ‘Daily PHPTIMESERIES’, both with the same result - failed dashboard widgets like gauges.
Note that this Daily Virtual Feed with a source feed doesn’t have to be public or consumed in a dashboard - it just has to exist in the list of possible feeds for a user. It breaks the dashboard & the API calls listed above (the dashboard uses the API calls).
I’ve tried creating a daily virtual feed and selecting a PHPFina source feed (which happens to be a power feed) the result looks fine in the standard graph view and I can create a dial widget in a dashboard. The existing dashboards all appear functional. I must be missing something else?
I am not sure nor do i know how to test.
However maybe, as timezone is only set correctly for the logged in user
I reckon though it should default to default time zone?
FYI, this issue still exists in 10.2.0, just updated about an hour ago.
It appears that this is happening because an unauthenticated user doesn’t have a timezone.
If I go into process_processlist.php and edit the function:
public function getstartday($time_now)
{
$now = DateTime::createFromFormat("U", (int)$time_now);
$now->setTimezone(new DateTimeZone($this->timezone));
$now->setTime(0,0); // Today at 00:00
return $now->format("U");
}
to hard code a timezone instead of looking up the user’s timezone, like this:
public function getstartday($time_now)
{
$now = DateTime::createFromFormat("U", (int)$time_now);
$now->setTimezone(new DateTimeZone('UTC'));
$now->setTime(0,0); // Today at 00:00
return $now->format("U");
}
everything works fine (doesn’t have to be UTC necessarily).
After looking through the code, only the daily virtual feeds look up a timezone for the user to set the start of the day. I believe it should default to the timezone of the user that owns the feed (as that’s what really matters for a daily feed to me).
There has been much discussion about this. You could use a ‘Dashboard’ timezone or a Device timezone or an Instance Timezone or use the server timezone or the browser timezone - they all have valid arguments!. This was never part of the original design so shoehorning it in is a little tricky.
Consider that you could have (like emoncms.org) multiple data sources all with different timezones, viewed by folk in different timezones again. Which is right?
As my earlier reply had been taken out to a separate thread, I’m posting a link here to where the error manifests for me. It could be TZ related or not.
@emrys solution is most of the way there, but I think better than bring this out to a potential setting in settings.ini its actually possible to get the feed timezone by fetching the feed userid from the feeds table as part of the VirtualFeed engine. This works both when logged in and for public dashboards.
But that is the userid of the person who created the Feed is it not?
How does that relate to the current user or a public dashboard? The Feed could be created by a user in a different timezone to the feed itself.
I wonder if a Feed needs a timezone attribute. Might solve a whole host of other issues with viewing data such as a ‘day’ of data relating to that feed. You could then workout when midnight was for each feed.
Is it not the case that, when viewing data, it should always relate to the local time that data was collected?
As I see it, the Viewer’s timezone has questionable relevance. It’s the timezone of the installation that matters most. The real problem appears to be the assumption that the two are the same thing.
And note, the timezone used to present the data needs to relate to the date of the data, in order to get daylight saving time right.
(Meaning, a graph viewed in the UK late on Saturday, 28th March relating to a UK installation will have the times axis reading 22:00 23:00 00:00 02:00 03:00 (as it does now), and if it’s an installation in New Zealand I’m looking at from here in the UK, on the morning of Saturday, 4th April, it will go 22:00 23:00 00:00 01:00 01:00 02:00 03:00 (which I think is exactly what you’d expect).
There might be a limited demand for the option for the display (not the underlying data) to be presented in the viewer’s timezone (i.e. the browser’s, and that’s not necessarily the same as the server’s). I’m not sure I can see a good reason for that though.
And this needs to take into account the API requests too.
