How to change a Timestamp variable value without changing it to a string?

Ignition
1

A script that had been working for months now causes a function that is passed the start time and end time to no longer work. Only the end time has an error and it is created from the start time.

I was using the system.date.addMinutes function to create an end time variable from the start time.

found_endTime = system.date.addMinutes(found_startTime, -10)

The found_startTime variable is type 'java.sql.Timestamp' and the found_endTime is type 'unicode'.

If I pass two timestamps that are both type 'java.sql.Timestamp' the function works.

2

I think you've mis-typed the variables in that sentence. Should the first one be found_startTime?

I was unable to reproduce the problem in Script Console on 8.1.31.

3

Sorry, that should have been the start found_startTime as type java.sql.Timestamp that works.

found_startTime is read using system.db.runNamedQuery and is a type java.sql.Timestamp and if I print the value it is something like "2023-12-05 20:26:14.777".

When I try to create the found_endTime with the system.date.addMinutes function it becomes type 'java.util.Date', looks like this "Tue Dec 05 20:16:14 CST 2023" and stops the function it's passed to from working.

I missed that it only becomes type 'unicode' after trying to change the format to match with the system.date.format function. It then looks like this "2023-12-05 20:16:14.000" but doesn't work.

4

That should be fine. That's just the human readable (but ugly) Ignition representation of the underlying date datatype. Don't format it until you need to at the last moment before display. Always leave them alone when passing from one function to another.

You'll have to share some information about that function. Post the code and format it correctly using the </> button.

5

I think you need to cough up the code for this mystery function you keep referencing.

3 Likes
6

Those are exactly the same thing. java.sql.Timestamp is a extension of the java.util.Date. When you "print" them out you get whatever representation has been chosen for that class. The information in the objects is the same.

If you function is dependent on a specific format, then you're, IMHO, doing it "wrong".

You should be using the date object up until you need it to be a string, and then do the format.

The "unicode" is just the encoding, the object is just a string.

What is failing in the function?

7

I don't know how it had been working before but I tried removing the format change step again and this time it now it works. I had tried that the other day, checking the type passed each time and seeing it still fail after each change until the type was java.sql.Timestamp. ???

8

'format' returns a string. Which is not a date, only the representation of a date.
date objects DO NOT have a format. Their representation does. What you see when you print a date is NOT the date, it's the string a call to their __repr__ or __str__ methods returns. They do pretty much what format does, except that you don't pick the format.
This is why you can get wildly different representations for two very similar objects. They might contain the same date, but print very differently.

So in trying to make one object look like the other, you ended up changing the underlying data, and more importantly its type.

Which is pretty much what @lrose said above.

1 Like
9

That is why I was using the format. In the end it must be in that format and it was working for some time. It seems it should have never worked, passing the date after it was formatted. Then it was still not working after I thought I'd removed the formatting step, so I was a bit lost. I must have changed something at some point, I just don't see how or when. Thanks for the info.