Hi guys!
My main server at the Michigan, an it's time zone is Chicago. However, my plants are ate the different time zones. I'm already have a lots of widgets that uses function now() for Tag History requests. In expression now() always return server time zone time. I tried to change Project->Project Properties->Designer->Timezone Behavior as well as Project->Project Properties->General-> Project Timezone. But this has zero influence on function now(). Does anyone has similar problem?
Scripts run on the gateway for perspective. You could try doing some time zone casting in each of your scripts if they are unique to the plant.
The object returned by now() doesn't have a timezone. It is UTC with millisecond precision wherever it is. It is shown relative to a timezone only where it is converted to a string. Convert it to a string in the gateway, you get the gateway timezone. So too with designers and Vision clients.
Perspective scripts and bindings run in the gateway, so you get gateway time. If you allow a date/time object to travel to the browser, it will get the underlying UTC milliseconds, and many Perspective components will understand and apply the browser time zone. If you need more control, you will need to use time-zone-aware string conversions in your gateway. See this topic and the linked topic within:
1 Like
Yes. That is exactly my problem. I want to use same script for all plants. I have 6 plants with 90% similar equipment . Also getTimezone() also return me tizmezone of the server.
Then what I would do is have each plant have a tag called timezone or something similar and have my scripts use that tag to convert depending on which plant they are running for. Just an idea based of the info provided, might not be the best for your use case depending on other factors.
1 Like
Thank you! This probably will be the best solution! I even can read variable from perspective timeZoneID. Depending on this variable I'll change input data. Just strange that this variable doesn't influence on system at all. 
1 Like
In Perspective, there is a client timezone property in the session props. A similar system tag exists for Vision, under the Client/User folder.
EDIT: You beat me to it! There is also a project properties setting to set the project timezone to whatever the client timezone is, in my experience it works most of the time but can get confused once scripting gets involved.
Well, I'm using now() to extract data from tag history and it return to me gateway timezone. For example: I need to know how long machine was ON form 6:00 to 12:00. And I wan to know this exactly at time zone weary machine is installed. But it return me 6-12 Michigan time zone 
The issue there isn't with now(), it's with the setTime(). Unfortunately, it's going to use the gateway timezone because the binding executes on the gateway.
To be able to use a local instant in time, you'll need to go ahead and convert from your local time to the gateway time, which is where the client timezone property will come in handy for scripting.
1 Like
That exactly how it I believe should work! For some reason it doesn't have any influence at all! I can put Australia tizmezone, nothing changes.
No, it does not return gateway timezone, because it HAS NO TIMEZONE!.
Go read everything I linked above again. I'll wait.
{ Tapping foot.... }
Ok, Now, it seems you need to construct date/time objects with specific times of day in specific timezones. The java ZonedDateTime class shown in those topics can be used to do so, then give you the java.util.Date to pass to the history bindings and/or queries.
I do wish it worked like that, but there's probably a reason it doesn't.
The client timezone variable only affects how times are displayed, not any inputs or calculations. Apologies if my post implied anything otherwise.
1 Like
Thank you. I have read, but this is over my level of understanding. I'm PLC programmer, don't really have to much experience with Java. Will ask our IT department to help me.
I found that it was mistake to save some money and buy Ignition. FactoryTalk is more expensive, but doesn't need Java knowledge to simply show 6 to 12 tag history 
You've made FactoryTalk do this same thing across multiple time zones with a database and server in one time zone?
You could so some simple python scripting in Ignition to accomplish what you want to do I think. After using both FactoryTalk and Ignition i'd say Ignition is 100x better. Are you displaying this information on screens around the facility?
OK, I think you just need a custom session prop (call it "tz_offset" for example), bound to a script transform to calculate the offset to go from local timezone to gateway timezone (probably making use of system.date.getTimezoneOffset()). Then, your Start Date and End Date expressions just need to addHours using tz_offset to get proper start and end times as corrected for timezone. Now, I'm not sure if this will break for the daylight saving time shift or something, but it should work the rest of the time.
Yes, on this stage I want to show workers and management how long each machine run. We have shift start at 6, then at 10 workers have lunch for 30 min. Some will finish at 12, some at 3:30. We need to know and see run time for each time period. It will connect SQL with History tag later to ERP and that it.
It is solution! Unfortunately system.date.getTimezoneOffset() return me gateway time zone. For sure, it is not problem to give each factory "offset" value. I just imagine someone who will install new machine and add it to SCADA after me. Also, I think simple time zone control without Java knowledge is thing that MUST be included.
2 Likes
Oh, right you are! It honestly slipped my mind that it would execute in the gateway after all, like anything else. Well, actually I found something better while looking at the manual.
If you check session properties, you will find device.timezone.utcOffset which does appear to actually give the client (or designer) time offset, so you can combine that with the gateway.timezone.utcOffset to convert back and forth. Still not a super clean one-step solution but better than having to keep track of it manually somewhere.
Thank you Felipe! I add adjustment for zone to my widget. Technically it is small script. Let's hope that with next update we will have some tool to work time zone. The main thing that didn't understand is how influence Project Properties on the project.
At manual it explained as:
Timezone for this project. Dropdown list includes the Gateway timezone, Session timezone, or specific timezones around the globe.
Looks like it doesn't have any real purpose 