Dashboard - Loggedin vs Public

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:

  1. Creating a Virtual Feed - Daily (this doesn’t happen with a ‘realtime’ virtual feed)
  2. 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).

Thanks @fillycheezstake

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?

Hm. In my previous post I forgot to mention it again, but they’re only broken when unauthenticated.

So

  1. Creating a Virtual Feed - Daily (this doesn’t happen with a ‘realtime’ virtual feed)
  2. Editing that Virtual Feed’s Process list to include a ‘Source Feed’
  3. Logout/access the public dashboard from another browser or Incognito mode or another device (or try the API call “/feed/list.json?userid=XXX”).

It may just be something on my installation of EmonCMS or maybe a PHP version issue.

Dont think is only your instalation

I still experience the same problem since the initial setup, and after all updates.
Running 10.1.13 now

Same error doing steps fillychezstake said

I also get the same error when accessing the public feed lists with the below api call:
philipahlers.com/emoncms/feed/list.json?userid=1 ]

Fatal error : Uncaught Exception: DateTimeZone::__construct(): Unknown or bad timezone () in /var/www/emoncms/Modules/process/process_processlist.php:1656 Stack trace: 
#0 /var/www/emoncms/Modules/process/process_processlist.php(1656): DateTimeZone->__construct(’’) 
#1 /var/www/emoncms/Modules/process/process_model.php(71): Process_ProcessList->getstartday(1579624492, Object(Process)) 
#2 /var/www/emoncms/Modules/feed/engine/VirtualFeed.php(83): Process->__call(‘getstartday’, Array)
#3 /var/www/emoncms/Modules/feed/feed_model.php(518): VirtualFeed->lastvalue(32) 
#4 /var/www/emoncms/Modules/feed/feed_model.php(384): Feed->get_timevalue(32) 
#5 /var/www/emoncms/Modules/feed/feed_model.php(360): Feed->redis_get_user_feeds(1) 
#6 /var/www/emoncms/Modules/feed/feed_model.php(369): Feed->get_user_feeds(1) 
#7 /var/www/emoncms/Modules/feed/feed_controller.php(54): Feed->get_user_public_feeds(‘1’) 
#8 /var/www/emoncms/core.php(60): feed_controller() 
#9 /var/www/emoncms/index.php(222): controller(‘feed’) 
#10 {main} thrown in /var/www/emoncms/Modules/process/process_processlist.php on line 1656

@TrystanLea is the issue with this error that if there is no user, there is no user timezone?

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?

@fillycheezstake is USA
i am Portugal GMT+1

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).

I’ve added a link to this to the GitHub issue.

I think it should be the browser timezone.

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?

3 posts were split to a new topic: On update problems with dashboards

Even after updating to lates 10.2.0
Still having same issue with public dashboard.
Logged in

PUBLIC

Console errors

Not sure why this problem persists

The Fatal Error persists:
Fatal error : Uncaught Exception: DateTimeZone::__construct(): Unknown or bad timezone () in /var/www/emoncms/Modules/process/process_processlist.php:1656 Stack trace: #0 /var/www/emoncms/Modules/process/process_processlist.php(1656): DateTimeZone->__construct(’’) #1 /var/www/emoncms/Modules/process/process_model.php(71): Process_ProcessList->getstartday(1582998937, Object(Process)) #2 /var/www/emoncms/Modules/feed/engine/VirtualFeed.php(91): Process->__call(‘getstartday’, Array) #3 /var/www/emoncms/Modules/feed/feed_model.php(523): VirtualFeed->lastvalue(32) #4 /var/www/emoncms/Modules/feed/feed_model.php(389): Feed->get_timevalue(32) #5 /var/www/emoncms/Modules/feed/feed_model.php(365): Feed->redis_get_user_feeds(1) #6 /var/www/emoncms/Modules/feed/feed_model.php(374): Feed->get_user_feeds(1) #7 /var/www/emoncms/Modules/feed/feed_controller.php(54): Feed->get_user_public_feeds(‘1’) #8 /var/www/emoncms/core.php(60): feed_controller() #9 /var/www/emoncms/index.php(220): controller(‘feed’) #10 {main} thrown in /var/www/emoncms/Modules/process/process_processlist.php on line 1656

1 Like

@emrys can you take a look please?

I think the problem is that it gets the TZ from the user, no user = no TZ.

@TrystanLea, perhaps either need to specify a default TZ in the settings or pick up TZ from the browser (if that is even possible).

Hi,
I have successfully created a public dashboard with the same widgets and graphs. I cannot re-recreate the issue.

steps taken to test:

  1. created new input via api (Input API Help)
  2. input posting to public feed
  3. processed input and posted to alternate public feed
  4. created graph to show value of both public feeds
  5. placed all widgets on dashboard referencing the new feeds
  6. set the dashboard to public
  7. posted new values to the input via api a couple of times
  8. pasted dashboard’s url to new browser window (not logged in)
  9. took this screenshot (all widgets and graphs showing ok)…

If I have missed a step please let me know so that I can re-create this issue…


fix:

$timezone set to false if user not logged in…

emoncms/process_processlist.php at master · emoncms/emoncms · GitHub #L1656
allows for default_timezone in settings file.

Could possibly pass a timezone offset with future requests from guest users?? timezone_offset_minutes

This request that should fix the error given above. It should have defaulted to UTC if no available. please comment if your error persists…

On current master branch default timezone set here:

1 Like

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.

Hope that helps in recreating the bug(s).

Thanks all for bearing with us with this issue. I was able to replicate an associated/same (I think!) issue here: fetch userid from feed table alongside datatype, remote static cache. · emoncms/emoncms@ab04267 · GitHub

@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.

I have commited the change to the master branch here: fetch userid from feed table alongside datatype, remote static cache. · emoncms/emoncms@ab04267 · GitHub this will work its way into the stable branch soon for update via the emoncms updater.

1 Like

What is a ‘Feed’ Timezone? How is it set and what does it mean?

Sorry, still the user timezone…

Instead of fetching the userid from the $session[‘userid’] I’ve changed the implementation to fetch the userid from the feed table e.g:

SELECT userid FROM feeds WHERE id=$feedid;

Then its possible to fetch the user timezone:

$timezone = $user->get_timezone($userid);

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?

1 Like

:+1:

:+1:

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.

1 Like

API requests are always a timestamp so timezone agnostic.

When I added the ability to feed JSON data in with a specified time, I made sure it handled timezones and converted to a timestamp correctly.