10-14-2020 07:03 AM
Hi,
I am using a 'Format Date/Time String' function to convert a timestamp obtained from 'Get Date/Time In Seconds ' in an RT target. The converted value lags the original time stamp by excatly one hour. Why is this so? Is there a way to correct this?
Thanks in advance
Best Regards,
Anurag
10-14-2020 07:31 AM
10-14-2020 07:33 AM - edited 10-14-2020 07:35 AM
Make sure the timezone of your RT target is configured the same as your host system!
There is no simple solution otherwise. The easiest would be to lobby for the views of the Flat Earth Society to be recognized as valid all around the globe 😀 and abandon timezones althogether. Unfortunately and very surprisingly, there seem to be quite a few countries who seem not very happy to change their timezones to be a different one than what they are using now! 😎
10-14-2020 08:28 AM
Your conversion from timestamp to string is missing the year.
So it probably isn't calculating DST because without the year, it won't know if a specific month and day would be a part of daylight savings time or not.
10-14-2020 08:31 AM
A common tip/solution is to use Universal time zone, there's a boolean input for that. That way you'll avoid the issues that often happens if the system is running as daylight savings is (de)activated.
That won't fix your current issue, but you can set your computer to UTC or convert it as you look at the data.
10-14-2020 09:13 AM
The problem persists, when the time stamp is fed to Format Date/Time String the output of it is 1 hour delayed. 😕
10-14-2020 09:18 AM
The use of UTC wont fit my need as I need the time resolution of at least 4 decimals of partial seconds.
10-14-2020 09:50 AM
@Anurag_NI wrote:
The use of UTC wont fit my need as I need the time resolution of at least 4 decimals of partial seconds.
UTC is a timezone and has nothing to do with resolution. One of the beauties of UTC is that is does not do Daylight Savings. So I am a fan of using UTC.
10-14-2020 11:09 AM - edited 10-14-2020 11:13 AM
Check the Time Zone settings as this works fine for me...
10-14-2020 01:11 PM - edited 10-14-2020 01:13 PM
I would use UTC internally, and only convert when a human needs to look at it. This would avoid potential issues with gaps in data (spring forward) or overwritten data (fall back).