# Timestamps fetched during a named query run during an SFC are of a different format than the exact same query run from the Script Console **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [October 24, 2023, 11:46pm UTC](https://forum.inductiveautomation.com/t/timestamps-fetched-during-a-named-query-run-during-an-sfc-are-of-a-different-format-than-the-exact-same-query-run-from-the-script-console/80935 "2023-10-24T23:46:31Z")\ **Posts on this page:** 1\ **Showing post:** 11
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [October 25, 2023, 6:47pm UTC](https://forum.inductiveautomation.com/t/timestamps-fetched-during-a-named-query-run-during-an-sfc-are-of-a-different-format-than-the-exact-same-query-run-from-the-script-console/80935/11 "2023-10-25T18:47:27Z")
> [@sherman](#): > > You think the simple json.dumps.encode is going to cause memory leaks? No. Encoding to and from JSON is easy. The section of what you're doing that is liable to cause issues is the 'sending over TCP' part. The "official" way to send socket data in Ignition would be the TCP driver, but it's a very leaky abstraction. If you've already got Python socket code, it really isn't a significant uplift to rewrite it to Java's idioms: > [@Opening Sockets to TCP devices using scripting](https://forum.inductiveautomation.com/t/opening-sockets-to-tcp-devices-using-scripting/76860/11): > > Yes. It's unfortunate, but you're just setting yourself up for failure if you use socket directly. Chat-GPT translated java.net.Socket equivalent of your snippet, that looks approximately correct: # Jython Client using java.net.Socket import java.net.Socket import java.io.IOException TCP\_IP = '192.168.1.100' TCP\_PORT = 17001 CONNECTION\_TIMEOUT = 5000 # The timeout is specified in milliseconds try: s = Socket(TCP\_IP, TCP\_PORT) s.setSoTimeout(CONNECTION\_TIMEOUT) out\_stream = s.g… The key insight is to use _Java_ libraries - you can still write things in Python, so it's not false to say that the scripting you write in Ignition is Python. It is also true that it's a thin veneer, because it's a _scripting_ language - we're not writing Ignition itself in Python, we're writing it in Java. > [@sherman](#): > > you're effectively telling me I can never trust that my system will work in production as programmed in Designer, and that I will be wrestling with SFC weirdness ad infinitum? That's not remotely what I told you. Nothing in Ignition is **non-deterministic**. I am trying to make sure you understand that _calling a script from the script console_ is not the same as _calling a script in an SFC_. Those two things are **different from one another** - but they are not going to be different **between themself**. If you want to test a script you are executing in an SFC, you absolutely can test isolated pieces of it via the script console provided you understand the differences implied by the different execution scope. The _point_ I was trying to make is that you cannot say "oh, it worked in the script console, therefore it will work in an SFC" in all scenarios - they are different execution scopes, fundamentally. > [@sherman](#): > > All that said, I am still _very_ disturbed that a **Ignition function** `system.date.format` does not work on an object coming out of a **Ignition Transaction Group** administered database via a **Ignition Named Query** while running in the **Ignition SFC Engine**. I was hoping to resolve this on the forums, but I will need to open a support ticket to deal with this now. Can you export a simple, self contained example SFC that is demonstrating this problem? --- _[View the full topic](https://forum.inductiveautomation.com/t/timestamps-fetched-during-a-named-query-run-during-an-sfc-are-of-a-different-format-than-the-exact-same-query-run-from-the-script-console/80935)._