It controls the automatic conversion of datetimes to strings in UI components that understand how to do it for you. Anywhere you do the string conversion, you have to apply any time zone.
1 Like
If it was up to me, I'd do all of the internal logic in UTC so that you only ever needed to worry about time zones when it comes to showing something to the end user. Of course we don't always have control over our data sources...
1 Like
In this particular case it return Chicago time, not Project time and not UTC. And this is exactly problem! I got what you told me, but again NOT UTC and not Project!
And Mounting time is 3:36 
It is being converted to a string in your designer for preview. It is showing you the object in your designer's time zone, because the preview is in your designer.
Everywhere it is converted to a string, a timezone will be applied. The object itself has no timezone.
That also means everywhere it is printed or logged, there will be a string conversion, and some timezone will be applied.
1 Like
No, it converted to time zone of gateway. Anyway, this possible to manage with "offset".
So, this is the difference between FactoryTalk and Ignition is like between new BMW and 20 years old Opel. Both will bring you home. At BMW you press button and drive home, or you run around opel eliminate all oil leakages, start it from third attempt and hope that fuel gage reading is correct. Of course car price does matter.
Whatever. Go back to your "BMW" if you like. I'm done with this topic.
Time and date is hard. Anyone that doesn't think so has never done anything complicated. No one has gotten it right from end to end. There are always stupid tricks you have to do. Hopefully your mix of technologies allow something more elegant that stringifying everything and implementing custom ISO8601 parsers but sometimes it doesn't.
1 Like
Sure. And people at BMW club are much different. I was stupid to buy old Opel when I have money for new BMW.
Or maybe you just think it's an Opel because you just can't open your eyes wide enough to see it's actually a freakin Lotus.
Especially when you keep trying to press a button to turn the ignition on while people keep telling you to put the key in and turn it.
Different technologies use different approaches. If you don't want to learn the Ignition way, it's up to you, but unless you do your opinion is uneducated and frankly quite pointless.
I might sound rude, but Phil as been trying repeatedly to explain what you're doing wrong, and you just won't listen. It's infuriating.
I'm not going to remove any posts, but let's not spend any more time on the somewhat tortured automobile analogy here, folks 
1 Like
You are 100% right, I'm just not good enough for Ignition.
Dates and times are notoriously complicated across many programming languages. Respect the complexity and embrace learning how to use them! Create a learning space and run through a bunch of examples. You may never come back to it after you conquer the problem, but the exercise often cements the knowledge.
Ignition has a bright future and you'd serve yourself well to commit to learning it, piece by piece.
When you're struggling with a concept and people are getting frustrated trying to help you, thank them for their patience and efforts. They care enough about you to get upset when they can't help you efficiently!
Edit: why does my name have cake?
No, you just hear what you want to hear. The solution was in 3rd message and it is "make offset". If you read carefully, you'll understand that I don't like that simple function like "I need to know how long machine run from this time for that time" must have some "offset" or "java programming". Just imagine, this is most basic function of any SCADA . I would say basic SCADA purpose is to provide tag history in some time diapason. So, you really think it must be some specific knowledge to use this function?
It will appear for one day on the anniversary of you joining the forum.