Hi Guys,
What if a user has two or more solar systems they are monitoring from their account and the sites are in different time zones?
At the moment I use tags to group feeds to a particular solar installation for that user.
Should I make another table in the database to match tags with timezones?
Interesting problem - not really one considered in the original design.
I did muse here (Dashboard - Loggedin vs Public - #37 by borpin) if each Feed should have a timezone attribute to try and provide a route to solving some of the TZ issues.
It would work retrospectively (as UNIX time is used internally) and could default to the TZ of the user creating the Feed.
@TrystanLea, @glyn.hudson @Gwil, thoughts around the practicality of that?
Hello @Alexander_Robinson @borpin
I think the easiest way to solve this at the moment is by creating two accounts one for each timezone.
As @borpin has noted there have been several conversations on how to improve the use of timezones in emoncms, I think a key point was to show graphs in the account timezone rather than the browser timezone… but we havent yet had the time to work on these unfortunately.
I disagree. The relative point to hook the Feed to is the TZ of the data source. I could live in the UK (account TZ) and be looking at data generated in Australia. I would not expect to see maximum solar to be at midnight! If you use the account TZ, that is what would happen.
What about public feeds/graphs?
I’m not suggesting it will change soon, but I do think it would be the right way to solve this.
Thanks Trystan, I thought of creating multiple users and saw a groups module was created.
Do you think having 1 main account for a user, and a dummy account for each solar installation would be the best solution? I haven’t updated my EMONCMS instance since I last posted on here 3 years ago so I would need to update it.
On another note, I have never used GIT before so I Haven’t been updating properly as I make small changes to my own instance. I will try and learn how to fork with GIT so I can become a bit more active in the development.
Yes thank you Borpin. Would associating each feed with a Timezone require an extra header/column added to the feeds table in the database?
The how, is outside my knowledge, I can just see that conceptually, it makes sense to do it that way. It is a design shift so would need more thought and is not going to happen for a while. Adding it to the feed meta data is (probably) the easy part!
I think of an account as being associated with a particular location & timezone and that all feeds associated with that account are also on the same TZ. So the feeds in Australia would be in say an account called SolarAU while the UK feeds would be in an account called SolarUK.
When a user accesses a public dashboard for SolarAU from the UK it could use the user timezone to show the time on the graph as Australia time…
Does that make sense?
Not really. If the person is in the UK (not logged in, public dash) it would surely use the Feed owners TZ (which might or might not be Aus time) and might or might not be the same as the Feed TZ.
BTW, Aus has several TZ so you would need a user account per location.
More importantly, I think it is not appropriate to associate the TZ with the user. I can see why it came about (a single nation centric design), but you must see it would be better if the TZ was related to the Feed?
Im still not really getting it.
If the person in the UK is not logged in, at present the time on the graph reflects the Browser timezone of the person in the UK. But we could instead show the time based on the timezone of the user who created the dashboard e.g the Australia TZ. They key assumption Im making is that each user account is location specific. and so why duplicate a settings for each users feeds when you can just access the timezone from the owner user account itself.
And that is the bit I think we should change. A user might have 2 properties, one here and one in France (i.e. 2 different timezones) both feeding into the same emonCMS instance (in fact I am sure this has come up before). If the Feed holds the TZ data, you can display both on the same dashboard.
When displaying a Feed’s data on a graph, the only X Axis that makes sense is local time to that feed. It then totally dispenses with this user/browser TZ issue.
I can see how that would work for a quite a lot of the places timezones are used in emoncms, I wonder how we would deal with multigraphs? with two feeds from different timezones?
What does it do now? Strictly it is probably wrong 
- one of the feeds is plotted against the wrong time!
Not saying it is without challenges, but I do think it is probably the right thing to do.
Remember that feeds data is always stored in UTC.
Timezone are just used for data visualisation on graphics and processors dealing with daily aggregations (using user TZ).
Changing from user to browser TZ is easy but adding support for feeds timezones, that will only be used for visualisation anyway, adds a level of complexity that requires a major refactoring of almost all classes of emoncms dealing with timezone.
If to change anything I would just add an override parameter to each graph so that users could override its timezone (different from user TZ) when building dashboads. Does this fit the purpose?
Yes of course that is true, but it is difficult to then know what the ‘local’ time is in relation to that Feed and therefore the relation to the sun position. This is important and currently solved at the visualization point rather than stored with the data.
Not necessarily. If you are doing some data analysis on when you use the most power (outside of a visualization) you’d need that info.
I wasn’t suggesting it would be easy, but I do think it might be the direction of travel. If you are suggesting a TZ could be offered as an override to a visualization, instead of that being manually inserted, could there not be the option to pull it from the feed meta data?
With Daylight Saving Time changing at different times in different parts of the world, and often on different dates in different years, that’s another variable that needs to be stored so that the applicable local time is known for historical data.
No, the system TZ will sort that relative to UTC/Unix Time.
[edit]
Although, I think the TZ system assumes it never changes i.e. Looking at histroical data, it assumes that the change from / to DST always happens on last sun in March for instance.
Looking back at historical data within the Eurozone could prove problematic when the formula changes unless they create a new TZ for the noDST TZ.
Agreed, but the Multigraph is the only outlier (or any graph that displays multiple feeds) - it would need to decide/be told what TZ to use (as it does now) if there were different TZs in the feeds selected.
The accumulators do all their work on UTC and then convert to display do they not? If I am on +4:00 and ask for data from a certain time, emonCMS takes the user TZ and goes to find the right UTC timestamp. The only difference would be it would use the Feed TZ instead of the user TZ?
The requirement is to display the data relative to the local time when it was collected not relative to the TZ it is being viewed from or the TZ of the user. I’m in the UK and want to look at a data feed from Aus. I am going to be surprised that the max solar input was at midnight. If the Feed does not hold the TZ, emonCMS has no way of knowing the local time of collection.
I know this was not part of the original design and I don’t have an issue with that. It works fine for local systems, but not for a global use.
If you want to have sensors on different TZ on the same user account, that is different and emoncms is not designed for that due to daily acumulators using user account that have one configurable TZ.
The relations are:
1 user : 1 TZ
1 user : multiple sensors
1 sensor : multiple feeds
Think this way: to do calculations with different feeds they must all be using the same ‘unit’. Industry standart says to use UTC and emoncms follows.
If you export data to be analysed on other platform, all data must be converted to the same unit before doing anything with it, UTC is the standard.
So just when displaying data it should be converted to the local TZ.
UTC does not have daylight saving.
Think on your requirement and see how you could possible have a multigraph displaying 2 TZ at the same time for 2 different feeds. You cant. Only the observator TZ matters and is what X axis label shows.
Yes and no. If you are trying to analyse solar data, outside of emonCMS, captured in Australia, you need to know the local time it was collected so you need the timestamp and TZ (which is why ISO 8601 strings are better in this case).
And I am not suggesting otherwise. The calculations are always done relative to UTC as at that point the TZ is irrelevant. However, when comparing data, it may need to be compared relative to the local time it was collected - so compare the amount of solar energy captured either side of midday in 2 different locations (and TZs).
Are you suggesting you accumulate more than one feed? If so then yes that needs to be accounted for, but if accumulating a single fed, at that point, the TZ is irrelevant.
I have already said (twice) you can’t and that is an outlying case that would need to be handled.
One way to handle it is to convert each displayed feed so it corresponded to the scale and externally decide if the scale is user TZ, browser TZ, a specified feed TZ or a completely different TZ selected. This is already done for the first 2.
We already have 2 TZs in use, browser and user. Trouble is neither are actually related to the Feed TZ - it is assumed the Feed TZ is the same as the user TZ.