I have a number of historical tags and when I plot them the axis (in a perspective XY chart) shows times that are 1 hour too early. I’m assuming it because of daylight saving, but I don’t know.
For example, I turned my system on this morning around 10:16am but the graph shows around 9:16am
And the database (MSSQL express) ‘t_stamp’ values are an hour off
If I convert the t_stamp value to a date as described here using
DATEADD(s, (t_stamp-18000000) / 1000, '1970-01-01 00:00:00') AS Expr1
I substracted 5 hours because my timezone is EST, which is -5 hours
I get the same values as plotted…
I’m using a nightly build (b2019071102) and the gateway is installed on a Windows 10 machine. My understanding is that the time is pulled from the OS but the time on the OS is correct
Just curious, what happens when you go to the SQL server and enter the word ‘time’ at the DOS prompt on that machine? And as to time zone, maybe I am incorrect, yet I thought that Central Time Zone varies between 5 and 6 hours difference with regarding to GMT depending on DST. Could your MSSQL server have been isolated from the Internet time server ( NNTP services ) when the time changed earlier this year? ( This is all theory, Your mileage may Vary (YMMV)) - Finally, as another forum user reminded me a few days ago, there is a support section as well as this forum. You may wish to look at the POLICIES for support prior to making a voice call. I believe you can get to the Support site best at: https://support.inductiveautomation.com Let’s just hope that this is not from the movie “Rocky Horror Picture Show”, song “Dance to the time warp again”- which is a reminder that the dates for observance of Daylight Savings Time were changed during a “W” type of administration.
Thanks for the response I guess I should have said that the database (MSSQL Express) is installed on the same machine that the Ignition Software/Gateway are all installed on. I’m in development mode right now so I have everything running on my PC.
I had a similar problem in the past that I'm not sure got resolved, but it was related to the EasyChart and it having an offset between discretes versus analogs, and it was most certainly timezone related (discretes and analogs were off by 5). What was weird was it showed perfectly fine on the local gateway, but the data was being split between the two systems, and only on the remote gateway did the issue show up. We never did figure that out, but I will tell you that looking at the epoch time stored in the DB was identical between the two systems.
Anyway, it is possible that the database is storing and presenting data from the database with an incorrect adjustment from the timezone. The database is capable of correcting on its own, but Ignition is dependent on the system time. If you don't need this (DB on the same machine), then you might want to check the timezone setting on MySQL. You might need to run this command or adjust a parameter on MySQL so it will also use the system time and let Windows adjust everything for you:
SELECT @@global.time_zone, @@session.time_zone;
The above code will return what MySQL is the setting.
SET GLOBAL time_zone='system';
This code will set it to use your system time. Even if the settings are correct for the timezone, running a Now() sql command can return the offset incorrectly. Something to check at least.
Thanks for the input, unfortunately I’m using microsoft sql server express (I put ‘MSSQL’ in my post for some reason). And my understanding is that SQL server uses the OS as well. But after reading your post I did a quick check of the database to see what time it thinks it is. Well it’s 2:29pm (14:29) and the database seems to agree. I ran this SQL command and the results are below. I’m in eastern standard time, which is UTC -5 hours but DST makes it UTC-4 hours now.
SELECT SYSDATETIME() AS [SYSDATETIME()]
,SYSDATETIMEOFFSET() AS [SYSDATETIMEOFFSET()]
,SYSUTCDATETIME() AS [SYSUTCDATETIME()]
,CURRENT_TIMESTAMP AS [CURRENT_TIMESTAMP]
,GETDATE() AS [GETDATE()]
,GETUTCDATE() AS [GETUTCDATE()];
Herbie seems to know more about it than I do, yet there is a Knowledgebase article by Anna Christian entitled “ClockDriftDetector warnings in the Gateway Console” posted 07/21/2016 08:11 A.M.
While the error involved of an hour is much greater than a second or two, there seems to be some important information in there about time synchronization. Most of what is said there pertains to system resources and Java Garbage collection. Again, if the issue is critical, you may want to read the support policies at https://support.inductiveautomation.com and ask them about it. Your e-mail response would be free unless you need ‘priority e-mail’. Not so with voice support- that depends on your account, if any.
Just an FYI- My PC here in Central DST seems to be set to UTC less *** SIX hours ***. How many time zones between Eastern and Central? My current time is 14:42.
I just took a look at the support page you referenced and as far as I can tell my PC knows what time it is. EST is an hour ahead of centeral so it’s 16:27 now (about 45min after your post).
Even the gateway seems to know what time it is
However, the XY charts still show the current time for the data as 15:25 instead of 16:25.
Then it looks like you may have found a BUG that pertains to either the newer versions of Ignition or the ability of your Windows10 environment to time-sync to the Ignition changes that are used to trigger the charting function. It has been a few months, yet I think that I remember someone else with a forum post about having difficulties with the XY Charts ( yet for a different reason- wanted to use reverse order on one axis ). It may be possible that the variables inside just the X-Y were expanded in order to allow the specific case mentioned… but that is not likely. If you looked at PC resources (previous) then you should get a good response. It should not be necessary to have IEEE1588 timing to get the accuracy of one hour. I would e-mail support, yet expect a delay unless it is a priority e-mail. My time here is 16:03 CDT. I suspect that IA will want the module versions…and maybe the Win10 long version.
Re: Other Issues reported on Forum Section: XY Chart issue with Zoom does not have a resolution, yet does not seem to apply.
Your response to other user of X-Y charts in May. (Paully with the fancy blue mobius-strip bowtie logo ).
No other obvious forum posts, so the cited Knowledge Base check re: previous post about time sync and PC resources ( eg. Hard-Drive access or other timer loss activities ) is the only other IA source of information about timing issues or X-Y charts that is easily found. The Knowledge base can be accessed from the support page, then searched.
I believe that should mean the clients show time as if they’re in the gateway timezone regardless of what timezone the client is in. Whether this is desired or not varies with the project. That said, it seems unlikely this is responsible for the issue you’re seeing with that setting. You could try another setting and see if it makes any difference.
Thanks, I don’t think I’ll have an opportunity to test until Monday but I’ll give it a try. In my case, clients and gateway will be in the same building so I think the ‘gateway timezone’ setting makes sense. But I’ll still play around with those settings.
Good luck. FWIW, I haven’t seen this issue in Perspective XY charts. We’re using Gateway Timezone setting as we prefer clients in other timezones see the same time values as locals they may be discussing the chart with (the charts are very locale specific; the timezone viewer is in isn’t relevant). When I pull it up on my phone in a different timezone than the server, the time on the x-axis shows server time as expected. If we were using multiple gateways in different timezones running the same project, we’d set it to the actual timezone desired so all clients show the same time on charts regardless of gateway.
Thanks for the input but I’m still not having any luck. I guess I’ll reach out to Tech support. As far as I can tell the historian tags are being saved into the database with the correct UTC time and my gateway displays the correct time. It’s just the XY chart is shifted an hour. I changed the the project timezone and it didn’t change the time on the chart at all. There is no difference on the chart whether I set timezone to New York or LA.
I wonder if it has something to do with the way I’m populating (binding) the data. I use the system.tag.queryTagHistory() function in a script to generate a dataset.
I just created a new project with two XY graphs one graph pulling data using
system.tag.queryTagHistory() function
and one graph just binding data to the tag historian and guess what..... The time with regular binding is correct. The queryTagHistory() function is my problem it doesn't adjust for daylight savings time.
FYI, the reason I'm using the query function to get the data is because my horizontal 'limit' lines disappear if I just bind the data. I have the limit lines associated with a second X axis because I'm using a single value memory tags to plot a horizontal line, I don't store the line data over time.
You can still have your control lines, it just takes a bit of code.
First create a custom property on the chart called LSL of dataset type.
Then create another custom property called Meas which contains your historical tag query.
Then in the property change event of the chart do code like this(Adjust for your tag names)
if event.propertyName=='Meas':
lcl = system.tag.read("PathToYourTag/LCL").value
lwl = system.tag.read("PathToYourTag/LWL").value
ucl = system.tag.read("PathToYourTag/1SigDev").value
uwl = system.tag.read("PathToYourTag/2SigDev").value
tmpDS = []
l = system.dataset.toPyDataSet(event.source.Meas)
hdr = ['t_stamp','1LCL','1LWL','1UCL','1UWL']
for i in range(0,len(l)):
tmpDS.append([l[i][0],lcl,lwl,ucl,uwl])
event.source.LSL=system.dataset.toDataSet(hdr,tmpDS)
chart = event.source
axes = chart.getYAxes()
axis = axes.get('Default Y Axis')
axis.setLowerBound(lwl - (lwl * .05))
axis.setUpperBound(uwl + (uwl * .05))
chart.setYAxes(axes)
chart.createChart()
l=None
It will look funky in designer when not in Run mode, but fills in when it preview and runtime.
