Time Stamps Are One Hour Ahead!!
Problem reported by Jonathan Garber - December 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
0
Eric McCarthy Replied
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
0
Jonathan Garber Replied
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.
0
Jonathan Garber Replied
Any response here...
0
Eric McCarthy Replied
Employee Post
This is currently under review. We will provide more information as it comes available.
Eric McCarthy
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Eric McCarthy Replied
Employee Post
We have been unable to replicate this issue. For additional help please open a support ticket.
Eric McCarthy
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com

Reply to Thread