Format Date/Time String

[Anurag_NI]

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

[ben64]

It's caused by the Daylight Saving Time. You can turn it on/off as in this snippet (maybe there's a better way)

Ben64

[rolfk]

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! 😎

[RavensFan]

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.

[Yamaeda]

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.

[Anurag_NI]

The problem persists, when the time stamp is fed to Format Date/Time String the output of it is 1 hour delayed. 😕

[Anurag_NI]

The use of UTC wont fit my need as I need the time resolution of at least 4 decimals of partial seconds.

[crossrulz]

---

@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.

[RTSLVU]

Check the Time Zone settings as this works fine for me...

[billko]

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).