# Report , Modify displayed date

**URL:** <https://forum.inductiveautomation.com/t/report-modify-displayed-date/97263>\
**Category:** Ignition\
**Created:** [October 15, 2024, 3:51pm UTC](https://forum.inductiveautomation.com/t/report-modify-displayed-date/97263 "2024-10-15T15:51:57Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Keith\_Magill](https://avatars.discourse-cdn.com/v4/letter/k/85e7bf/32.png) [@Keith\_Magill](https://forum.inductiveautomation.com/u/Keith_Magill)\
**Post date:** [October 15, 2024, 3:51pm UTC](https://forum.inductiveautomation.com/t/report-modify-displayed-date/97263/1 "2024-10-15T15:51:57Z")

</div>

Hello All,

I have a report that is running fine except for the displayed time stamp.  
I have a transaction group the triggers at 02:00 AM. The transaction actually logs all of the metered total from the prior day. It then clears the totals to zero.. All of that works fine. The issue I have is when running the report query based on "t\_Stamp" all of the data displayed is from the prior day. Can I apply math to the @t\_stamp@ so it shows -1day? So for a report run on Oct 2nd, it would display as Oct 1st...

---

<div class="post-metadata">

**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\
**Post date:** [October 15, 2024, 6:20pm UTC](https://forum.inductiveautomation.com/t/report-modify-displayed-date/97263/2 "2024-10-15T18:20:31Z")

</div>

Post a screenshot of your report parameters and data sources configuration, for the best answer; however, it sounds like you would just do it in your query. The syntax is dependent on your db flavor (mysql, postgres...)

---

<div class="post-metadata">

**Author:** ![Keith\_Magill](https://avatars.discourse-cdn.com/v4/letter/k/85e7bf/32.png) [@Keith\_Magill](https://forum.inductiveautomation.com/u/Keith_Magill)\
**Post date:** [October 17, 2024, 6:47pm UTC](https://forum.inductiveautomation.com/t/report-modify-displayed-date/97263/3 "2024-10-17T18:47:48Z")

</div>

dkhayes117,  
Sorry for the delay.. Field work..  
I am using MySQL as the database.  
Data is collected using a triggered transaction group. Issue is that we activate the trigger at 2:00AM instead of midnight in case production runs past midnight. This makes the data's "T-Stamp" value a "day ahead" of the production values.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/d/1defa063e7b527f113b4e3f5ebe2c85ff742f44d.png)

Report is basic to say the least.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/f/3fcb0685c274f55462fc32a2186f1045003330eb.png)

I am hoping for a way to modify the @t\_stamp@ value to read as the prior day.

Thanks for your help..

---

<div class="post-metadata">

**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\
**Post date:** [October 17, 2024, 7:00pm UTC](https://forum.inductiveautomation.com/t/report-modify-displayed-date/97263/4 "2024-10-17T19:00:56Z")

</div>

Modify it in the query,

```python
select 
   ...,
   ...,
    ADD_DATE(t_stamp, INTERVAL -1 DAY) as production_date
from IngSkid_Totals
... 

```

EDIT:  
Another method could be to add another field that gets captured in the transaction group called `production_date` which would log an expression value `addDays(now(0),-1)`

Then `t_stamp` would be when data was captured and `production_date` is the workday it represents.

---

<div class="post-metadata">

**Author:** ![Keith\_Magill](https://avatars.discourse-cdn.com/v4/letter/k/85e7bf/32.png) [@Keith\_Magill](https://forum.inductiveautomation.com/u/Keith_Magill)\
**Post date:** [October 17, 2024, 7:33pm UTC](https://forum.inductiveautomation.com/t/report-modify-displayed-date/97263/5 "2024-10-17T19:33:50Z")

</div>

I will try them individually.  
The transaction group version sounds to be the best approach..