Hello everyone, I’m facing a significant challenge with the data logging functionality in FTV-SE (version 10). How do you address the changes associated with daylight saving time (DST)? For the alarm and diagnostic logs, it’s not an issue since they consistently utilize UTC. However, it appears that the data logs are recorded in local time. I have included four screenshots demonstrating the effects of switching to daylight saving time. I didn’t adjust the clocks; I simply enabled or disabled daylight saving time to simulate the upcoming changes that occur in March and October. Essentially, the timestamps in the data log, trends, and application only reflect the correct time after a Windows restart post-DST change. Depending on whether I’ve restarted the runtime or Windows after toggling daylight saving time, I see different timestamps displayed in FTV and on the data logs. This inconsistency could lead to dissatisfaction for customers, particularly concerning audit trails, trend analysis, and reporting. I can’t be the only individual encountering this issue; how do you handle time transitions in FTV? Your insights would be greatly appreciated!
I encountered a similar issue in the past with FTView version 7.00. To resolve it, we decided to disable daylight saving time on all servers and set the time zone to Coordinated Universal Time (UTC). While I'm not certain if this solution will work for you, I recommend considering an update to your system time using a VBA script. Although I haven't personally tested this approach, it could be a worthwhile option to explore.
Chopin mentioned, "I encountered a similar issue with FTView 7.00 in the past. We resolved it by disabling daylight saving time on all servers and configuring the time settings to UTC. While I'm unsure if this solution will be effective for you, it's worth considering an update to your system time using a VBA script. I haven't personally tested this, but it could be beneficial to try. Although turning off daylight saving time is an option, it's not typically my preferred choice. I'm exploring the possibility of manually adjusting the system time instead. Alternatively, I may need to advise the customer to shut down the plant the evening before the time change and restart it after 3 AM. For anyone dealing with time synchronization issues in FTView, these strategies might help."
In continuous manufacturing environments where downtime costs exceed £10,000 per minute, I have established the server configuration to UTC+00:00, irrespective of local time zones. I lack confidence in the thorough testing of industrial automation software by developers, especially regarding daylight saving time and time zone discrepancies. My goal is to simplify operations for my team by eliminating the need for them to manually adjust hours in the data they receive. For example, I encountered a situation in Australia where a system failed to implement a crucial Microsoft update—this issue arose after the government modified daylight saving time regulations in 2009, leading to significant operational disruptions. By using consistent time standards and staying updated on software patches, companies can avoid costly interruptions and streamline their processes effectively.
In the world of continuous manufacturing, where downtime can exceed £10,000 per minute, I recommend configuring the server to UTC+00:00, regardless of the local timezone. My confidence in industrial automation software developers is not strong enough to trust that they rigorously test all functionalities for daylight saving time and timezone discrepancies. The alternative of my operators having to manually adjust data for time differences is not ideal. During my time in Australia, I encountered a system that lacked the necessary Microsoft update (following the government's modification of daylight saving dates in 2009), and it caused significant issues. Now, regarding the management of timestamps in reports and alarms: How do you address the fact that all trends, audits, and alerts display in UTC+0 rather than the local timezone? Typically, clients expect their logs and reports to reflect local time for ease of interpretation. Additionally, as a side note, I attempted to manually adjust the time using VBA. While I was able to modify the system's hour and minute settings, resulting in the display and trends reflecting the updated time, the actual data stored in the SQL database remained unchanged until a Windows reboot occurred. Best practices for time management in industrial automation should prioritize local time synchronization to avoid confusion and ensure efficient operations.
We've encountered similar issues with customers who were confused by the one-hour time shift. However, we successfully communicated the challenges associated with implementing this change, which ultimately led to their acceptance. One potential solution using SQL is to create an additional column labeled 'local_time_zone.' You can then develop a stored procedure or function that adjusts your original timestamp by one hour. This way, when you retrieve data for reporting or trend analysis, you can utilize the updated 'local_time_zone' timestamp. While this may not be the optimal approach, it could provide some relief. Additionally, if you explore the SQL settings deeply, you can modify the server's time configuration to match the local timezone. It's important to note that this setting differs from the server's operating system time zone; it's specifically within the SQL environment. This adjustment could effectively resolve the issue without requiring the creation of procedures or a server reboot.
Hey there! I totally get your frustration with the DST changes in FTV-SE; it can be a real pain. One workaround I've found is to set up a scheduled task to restart the runtime service automatically after toggling DST. This way, it minimizes the manual intervention needed and ensures that your logs reflect the correct local time. Additionally, keeping a note of how DST affects your logs can help during audits or when reporting, so you can provide context to any discrepancies. Hopefully, Siemens can streamline this process in future updates!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: A1: In FTV-SE, data logs are recorded in local time, which can cause inconsistencies during the transition to or from daylight saving time. Timestamps in the data logs, trends, and applications may not reflect the correct time until after a Windows restart following a DST change.
Answer: A2: Alarm and diagnostic logs are unaffected by daylight saving time changes because they consistently utilize Coordinated Universal Time (UTC), which does not change with local DST adjustments.
Answer: A3: The inconsistencies can lead to issues in audit trails, trend analysis, and reporting, potentially causing customer dissatisfaction due to inaccurate or misleading data representations.
Answer: A4: After a daylight saving time change, a Windows restart is required to ensure that timestamps in FTV-SE reflect the correct local time.
Answer: A5: The thread does not provide a solution for handling DST transitions without a restart. Users often face different timestamps until Windows or the FTV runtime is restarted,
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.