Hey guys,
I am trying to display a millisecond timestamp in perspective using the browser's local timezone. Despite this, I continue to have the gateway's timezone being used, even though I explicitly defined it to use the client's timezone.
Is there anything I am missing here?
timezone setting:
property binding:
I expect it to show MST instead of CST.
Any thoughts?
The transform runs on the gateway so it cheerfully ignores the project setting. As far as I can tell, the Project time zone property only applies to components where the dates get formatted automatically. A good example is the Date Time Input component. If you were to feed your milliseconds into a binding on the value property of one of those, you'd see the formatted date would display with the project time zone.
Huh, I was always under the assumption that component property bindings ran in the client scope and not the gateway scope.
It's Perspective, everything executes on the gateway scope. I really do wish the date functions would automatically take the project timezone into account or have a configurable time zone parameter.
Well I guess that makes sense. I could probably use the session TimeZoneID somehow to format the datetime into the correct timezone.
I obviously didn't dig hard enough. This came up once I refined my search slightly:
This is my final solution:
def transform(self, value, quality, timestamp):
from java.util import TimeZone
from java.text import SimpleDateFormat
tz = TimeZone.getTimeZone(self.session.props.timeZoneId)
sdf = SimpleDateFormat("E MMM d, h:mm:ss a z")
sdf.setTimeZone(tz)
return "Scheduled for: " + sdf.format(system.date.fromMillis(value))
Changing Project Timezone to Client didn't seem to have any effect on the standard Perspective views when rendered on a browser page for me.
Adding a Property Binding to the Session Props timeZoneId of this.props.device.timezone.id did change the presented time to the local timezone as set by the browser (chromium, developer tools, sensors, location -> override to whatever you want to test and F5 to reload the Perspective page)
Once we add a timezone argument to the scripting/expression functions, it should be "easy" for us to pass through a contextual timezone automatically, and for you to override it if you have some other purpose. I'll make a note on the existing internal ticket discussed in that other thread.
You really should not be doing imports in transforms (or any other defs where you can avoid it). Delegate to a project library utility script, like shown here:
I found this article which seems helpful
There might be a clue in there about why changing Project Timezone to client didn't change anything for me. The project Component Session Property was hardcoded (by default?) to America/New York and that value overrides the Project Timezone. Maybe setting the value to "" would enable the Project Timezone setting? (Note that I haven't tested this.)
Unfortunately the article starts out defining the Perspective Session Timezone and discussing how it is set but then transitions to Browser timezone when talking about how things are displayed. Those are not the same thing, and my experiments yesterday indicates that the components don't use Browser timezone, at least not the ones that I was looking at.
Are the module imports not cached or something when the def runs? Do you say this because it's reimporting the module every time the function runs?
No (the imported module itself is persistently cached, but the import statement won't find it without an expensive lock), and yes.
Same with def nested within another def, mostly.