Time Stamps Are One Hour Ahead!!

Problem reported by Jonathan Garber - 12/28/2017 at 4:09 PM

Not A Problem

When viewing the database response from the API we can see timestamps on tickets, call logs, time logs etc. are all one hour ahead. This wasn't an issue when we were in DST and we didn't know SmarterTrack wouldn't handle DST vs Non-DST correctly.

We have Time Logs where the employee will enter 5:00 pm to 6:00 pm but the actual database entry shows 6:00 pm to 7:00 pm when we query time logs via the API.

The timestamps are supposed to be UTC as well according to documentation but they aren't.

Is anyone else seeing this in SmarterTrack?

5 Replies

Reply to Thread

Eric McCarthy Replied

12/29/2017 at 8:51 AM

Employee Post

What time zone are you using for your SmarterTrack? We would like to use the same information to try and replicate your issue.

Eric McCarthy Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com

Jonathan Garber Replied

12/29/2017 at 9:40 AM

Eastern Time (US & Canada)

Like I said the timestamps are supposed to be UTC in the DB according to your documentation on external providers/API calls etc. However the timestamps are stored in our timezone Eastern Time they are just now one hour ahead (they are not accounting for DST/non-DST)

This is the "datereceviedutc" from one of our tickets via GetTicketProperties at the svcTickets endpoint on the API. This ticket was made at 3:31 PM Eastern Time Non-DST

Here is a snippet of the array reported back to us...
Array ( [datereceivedutc] => 2017-12-26 16:31

So the Database returned 4:31 PM which would be eastern time zone in DST. Incorrect, as we are not in DST now. SmarterTrack itself on the ticket admin shows the correct time 3:31PM.

The timestamp returned is also not in UTC format like it should be according to documentation and the field name "datereceviedutc"

UTC Time for this entry would have been 2017-12-26T21:31:00Z

Now if the Database was recording the correct time for EasternTime Non-DST
It would have reported 2017-12-26 15:31 which in the proper formatted UTC would be 2017-12-26T20:31:00Z

This is what I can see on my end, I didn't write the application so I don't exactly know how the API is coded to respond. I haven't looked at the field raw in the database either. So I don't know if the API attempted to translate the time to Eastern Time when it returned the results or if that entry is the raw entry in the DB.

Hopefully you guys can figure this out and resolve the issue. The entry should have been returned in actual UTC time. If you guys are going to adjust it to return in our timezone, that works too, it just needs the correct time according to DST vs Non-DST.