# Created\_at starts from 1970 even when the timestamp on postgres is correct **URL:** \ **Category:** Ignition\ **Created:** [September 25, 2025, 12:53am UTC](https://forum.inductiveautomation.com/t/created-at-starts-from-1970-even-when-the-timestamp-on-postgres-is-correct/110955 "2025-09-25T00:53:41Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![k.jin](https://avatars.discourse-cdn.com/v4/letter/k/f1d935/32.png) [@k.jin](https://forum.inductiveautomation.com/u/k.jin)\ **Post date:** [September 25, 2025, 12:53am UTC](https://forum.inductiveautomation.com/t/created-at-starts-from-1970-even-when-the-timestamp-on-postgres-is-correct/110955/1 "2025-09-25T00:53:41Z")
Hi everyone, I just came to notice that created\_at column returns a timestamp starting from 1970 even when the timestamp on postgres is correct. On postgres side, created\_at is basically now() when a row is inserted, and this matches the clock on OS. Data type is time with time zone. However, when a query is made from Ignition, values on created\_at column starts from 1970 for some reason. Is there a reason why this is happening? I thought it was one of those epoch time issues, but created\_at column is never empty and the timestamp on postgres side are synced to the OS time. Many thanks in advance. ---
**Author:** ![Cose\_Peter1](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cose_peter1/32/79174_2.png) [@Cose\_Peter1](https://forum.inductiveautomation.com/u/Cose_Peter1)\ **Post date:** [September 25, 2025, 2:00am UTC](https://forum.inductiveautomation.com/t/created-at-starts-from-1970-even-when-the-timestamp-on-postgres-is-correct/110955/2 "2025-09-25T02:00:26Z")
You might have to share your query. Both the insert query and also the select query. ---
**Author:** ![k.jin](https://avatars.discourse-cdn.com/v4/letter/k/f1d935/32.png) [@k.jin](https://forum.inductiveautomation.com/u/k.jin)\ **Post date:** [September 25, 2025, 2:25am UTC](https://forum.inductiveautomation.com/t/created-at-starts-from-1970-even-when-the-timestamp-on-postgres-is-correct/110955/3 "2025-09-25T02:25:41Z")
Hi Cose, thank you for replying. Insert and select queries are as easy as they can get: `insert into ams_recipe (` `crush_duplicate,` `crush_clean,` `crush_duplicate_mass,` `crush_primary_mass,` `crush_flow_rate,` `name,` `crush_all_to_waste,` `crush_retain,` `recipe_number)` `values (` `:split_type,` `:cleaning_required,` `:duplicate_cup_mass,` `:primary_cup_mass,` `:flow_rate,` `:recipe_name,` `:all_to_waste,` `:retain_required,` `:recipe_number)` created\_at is inserted on the postgres side with now() select query is literally just `select * from ams_recipe` ---
**Author:** ![dgillbee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dgillbee/32/73838_2.png) [@dgillbee](https://forum.inductiveautomation.com/u/dgillbee)\ **Post date:** [September 25, 2025, 5:00am UTC](https://forum.inductiveautomation.com/t/created-at-starts-from-1970-even-when-the-timestamp-on-postgres-is-correct/110955/4 "2025-09-25T05:00:58Z")
I just tested the same setup. My human readable column in Postgres (timestamp data type) is converted to the Epoch time (time since 1970) when read into JSON using a named query. Surprisingly if you return the the query as a dataset, a date datatype is still used. You can use the `fromMillis({value})` expression to convert it back to a readable date. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/1/517d0a1bed69623207e61af37b73f646787a787b.png) ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [September 25, 2025, 8:37am UTC](https://forum.inductiveautomation.com/t/created-at-starts-from-1970-even-when-the-timestamp-on-postgres-is-correct/110955/5 "2025-09-25T08:37:31Z")
How many digits are created\_at values? Are you sure it's millis and not in seconds instead? Ignition/Java expects millis timestamps ---
**Author:** ![k.jin](https://avatars.discourse-cdn.com/v4/letter/k/f1d935/32.png) [@k.jin](https://forum.inductiveautomation.com/u/k.jin)\ **Post date:** [September 25, 2025, 9:31pm UTC](https://forum.inductiveautomation.com/t/created-at-starts-from-1970-even-when-the-timestamp-on-postgres-is-correct/110955/6 "2025-09-25T21:31:33Z")
This is what’s on the postgres side: 2025-09-26 09:27:24.374311+12 I think what @dgillbee is saying is the root cause of the problem. I wonder if this is an expected behavior or a bug. ---
**Author:** ![k.jin](https://avatars.discourse-cdn.com/v4/letter/k/f1d935/32.png) [@k.jin](https://forum.inductiveautomation.com/u/k.jin)\ **Post date:** [September 25, 2025, 9:58pm UTC](https://forum.inductiveautomation.com/t/created-at-starts-from-1970-even-when-the-timestamp-on-postgres-is-correct/110955/7 "2025-09-25T21:58:55Z")
![Untitled](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/5/95562774f22375d648a07524d6612e89c8aae3bb.png) Thank you for trying out! I am not sure how you’ve managed to get the correct timestamp to show up on your Query browser? As shown in my picture, created\_at columns all start from 1970 when the timestamp on postgres side seem to be correct. FIXED: alright, stupid mistake on my side.. data type on postgres was set to ‘time with time zone’ not ‘timestamp with time zone’. Setting the data type to ‘timestamp with time zone’ on created\_at fixed the issue.