# Historian t\_stamp format

**URL:** <https://forum.inductiveautomation.com/t/historian-t-stamp-format/73954>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [May 19, 2023, 2:06pm UTC](https://forum.inductiveautomation.com/t/historian-t-stamp-format/73954 "2023-05-19T14:06:56Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Austin\_Jasmer](https://avatars.discourse-cdn.com/v4/letter/a/2acd7d/32.png) [@Austin\_Jasmer](https://forum.inductiveautomation.com/u/Austin_Jasmer)\
**Post date:** [May 19, 2023, 2:06pm UTC](https://forum.inductiveautomation.com/t/historian-t-stamp-format/73954/1 "2023-05-19T14:06:56Z")

</div>

I was wondering how to change the t\_stamp data to be in a datetime format? It is currently only a long number which is difficult to use.  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/6/060d54fa7db5ee561508a6c4c0beecb8763cd018.png)

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

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 19, 2023, 2:10pm UTC](https://forum.inductiveautomation.com/t/historian-t-stamp-format/73954/2 "2023-05-19T14:10:41Z")

</div>

It is converted to `java.util.Date` for you by the tag historian's query functions. It is stored as a long integer (UTC epoch milliseconds) to work around some database brands' poor support for reliable UTC-based timestamp storage.

Use the tag historian's query functions. If you must use direct SQL for some reason, you will need to convert these yourself, taking care to get the timezones right.

---

<div class="post-metadata">

**Author:** ![ajdewhirst1](https://avatars.discourse-cdn.com/v4/letter/a/bbe5ce/32.png) [@ajdewhirst1](https://forum.inductiveautomation.com/u/ajdewhirst1)\
**Post date:** [May 19, 2023, 2:24pm UTC](https://forum.inductiveautomation.com/t/historian-t-stamp-format/73954/3 "2023-05-19T14:24:29Z")

</div>

There is also a knowledge base article here:

[https://support.inductiveautomation.com/hc/en-us/articles/360047136252-Understanding-Tag-Historian-Timestamps](https://support.inductiveautomation.com/hc/en-us/articles/360047136252-Understanding-Tag-Historian-Timestamps)

---

<div class="post-metadata">

**Author:** ![brandon1](https://avatars.discourse-cdn.com/v4/letter/b/ea666f/32.png) [@brandon1](https://forum.inductiveautomation.com/u/brandon1)\
**Post date:** [May 19, 2023, 2:58pm UTC](https://forum.inductiveautomation.com/t/historian-t-stamp-format/73954/4 "2023-05-19T14:58:48Z")

</div>

I think I know the answer but just to confirm. The UTC epoch milliseconds format does not suffer from the Year 2038 issue correct?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [May 19, 2023, 3:06pm UTC](https://forum.inductiveautomation.com/t/historian-t-stamp-format/73954/5 "2023-05-19T15:06:30Z")

</div>

It could, this problem exists when a system stores this value in a 32-bit signed integer. If it's stored as 64-bit then it's not a problem.

---

<div class="post-metadata">

**Author:** ![brandon1](https://avatars.discourse-cdn.com/v4/letter/b/ea666f/32.png) [@brandon1](https://forum.inductiveautomation.com/u/brandon1)\
**Post date:** [May 19, 2023, 3:22pm UTC](https://forum.inductiveautomation.com/t/historian-t-stamp-format/73954/6 "2023-05-19T15:22:26Z")

</div>

Just for posterity I checked in the Maria DB we are using and it is defined as a bigint(20). This is clearly much larger than a 32-bit signed integer.