# \[Solved\] History Storing, but not retrieving on a binding **URL:** \ **Category:** Ignition\ **Tags:** ignition81, perspective, database\ **Created:** [June 30, 2023, 10:24am UTC](https://forum.inductiveautomation.com/t/solved-history-storing-but-not-retrieving-on-a-binding/75763 "2023-06-30T10:24:46Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Alex\_Leech](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/alex_leech/32/39391_2.png) [@Alex\_Leech](https://forum.inductiveautomation.com/u/Alex_Leech)\ **Post date:** [June 30, 2023, 10:24am UTC](https://forum.inductiveautomation.com/t/solved-history-storing-but-not-retrieving-on-a-binding/75763/1 "2023-06-30T10:24:46Z")
Hi all, Been struggling to get historical logging working correctly, and decided to do some digging today. The problem seems to be that the data is storing correctly in the database (perhaps?), but then not being retrieved correctly by the ignition tag binding. I've created a band new database and brand new tag. The historical logging has been configured as follows on the tag: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/6/e65df454e5e125389939771a1737190c21fbf0cc.png) Setting this running, and varying the flow gives us some results in our database: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/7/b/7b12ccdd43506041d5a2a198614073a389fc0a9f.png) Noted that the first t\_stamp here recorded is 1688125471633 = Friday, 30 June 2023 11:44:31.633 (GMT). This seems to not be correct as I am currently in GMT+1, and then +1 for the summertime (DST). I.e. Time now in DST is Friday, 30 June 2023 12:44:31.633 (GMT+2) The result of this is seen when I try a tag history binding as only one data point comes back, and it is the first point of the table, but shown as 'in the future': ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/a/aa9517338681cc6b8a852f82e08f170e32fbeff4.png) The database and gateway are all on the same VM - How do I fix this odd problem? Does the gateway have its own timezone somewhere thats incorrect? Or is it not correcting for daylight savings? Thanks! Alex Edit: To add tags ---
**Author:** ![Alex\_Leech](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/alex_leech/32/39391_2.png) [@Alex\_Leech](https://forum.inductiveautomation.com/u/Alex_Leech)\ **Post date:** [June 30, 2023, 10:31am UTC](https://forum.inductiveautomation.com/t/solved-history-storing-but-not-retrieving-on-a-binding/75763/2 "2023-06-30T10:31:44Z")
Historical Binding configuration: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/a/da35dc99e3fac9fec5c994196e328d31e464905a.png) Context: I'm trying to draw a chart that shows the flow over the last 5 minutes for commissioning. ---
**Author:** ![Alex\_Leech](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/alex_leech/32/39391_2.png) [@Alex\_Leech](https://forum.inductiveautomation.com/u/Alex_Leech)\ **Post date:** [July 13, 2023, 7:56am UTC](https://forum.inductiveautomation.com/t/solved-history-storing-but-not-retrieving-on-a-binding/75763/3 "2023-07-13T07:56:48Z")
TLDR: Device OPC server time needs to be correct if using On Change. Hullo peeps, Quick followup for anyone finding this! After a chat with support it was found that the OPC server time in the PLC that it was drawing from was wrong. When using 'On Change', the historian now takes the timestamp from the OPC server. The ability to use the local timestamp when using 'On change' was removed as per the below from Colby Clegg. > [@How to set the Timestamp Source to Value on a tag](https://forum.inductiveautomation.com/t/how-to-set-the-timestamp-source-to-value-on-a-tag/26868/8): > > Hi, Sorry for the delay- this setting was removed in 8 in an effort to start to reduce the multiple layers of timing definition and to get down to single sources of data. The system timestamp only makes sense in situations where the system is scanning tags to collect values. In cases where the values are coming from the sources and being evaluated as they change, it makes sense to use the source timestamp. So, we’ve made the logic that was previous driven by this setting more implicit. If the… This post outlines the same issue: > [@History t\_stamp in the future](https://forum.inductiveautomation.com/t/history-t-stamp-in-the-future/29507): > > I’m having trouble with the history of a tag that I cannot work out. I setup history on a tag, and when it’s displayed in a sparkline or chart, it displays data from 6 hours ago. If I look at the database, the timestamp on the data is 6 hours in the future. Database table: [image] t\_stamp conversion: [image] The Gateway server is set to UTC+10: [image] Ignition shows the correct time: [image] The database shows the correct time: [image] I’ve tried restarting Ignition, restarting the … Have a great day!