The script seems to be OK, but probably an epoch date with miliseconds is an issue for AROutput step.
I would try adding a 'Select values' step just after your step with the script and set Format on 'Meta-data' tab to the one with seconds (like: yyyy/MM/dd HH:mm:ss)
Looking at the date values in the database, we are seeing numbers like 2457568 and 2457590. Looking at the remedy form, the field type is a "Date" only field (holds no time).
From the Remedy UserTool, the system appears to resolve the 2457568 to be 07/28/2016.
Putting this date into an Epoch converter, we get 1469664000 for 07/28/2016 @ 12:00am UTC. Big difference in numbers.
After some digging, we found a BMC Communities article from 2013 that gave a solution.
It seems that the the date field contain the difference in days as the info from the concept manual said:
date data type
The data type used for fields containing date values. Date values can range from January 1,
4713 B.C.E., to January 1, 9999 C.E. Date values are stored as the number of days from
the beginning of the date field’s range. For example, January 1, 2009, is stored as the
number 2454833 because it is 2,454,833 days after the first day in the date range.
(page 80 from the Concept manual)
In fact it seems the the date field are keeping a julian date and the formula to change the julian date to timestamp would be:
unix_time_stamp = ( JD -2440587.5) * 86400
OK, so it's a Date field, not Date/Time (you used a term "timestamp")
Great you found a solution.
select ..., to_char(to_date(<your Date field>, 'j'), 'yyyy-mm-dd'), ...from ... (in case of Oracle)