Forum Discussion

ArchiveUser's avatar
ArchiveUser
Qrew Captain
8 years ago

Timestamp stored via API being returned as UTC in notification email

I have a notification that triggers when a timestamp field is updated via an API EditRecord call.  The timestamp is generated by JavaScript and is stored in QB in UTC time.  This isn't a problem when I retrieve that timestamp and then adjust it back to local time within JavaScript.  The problem I'm faced with now is that the timestamp displayed in the notification (and in forms as well) is still UTC time.  If I were to choose a date/time value for that field through the UI, it still seems to store the value in the database as UTC but will adjust itself to the local time appropriately when viewed on a form.  Ultimately, my question is whether there's a way through a formula field that I can adjust the timestamp stored through the API to the user's time zone so that I can use that field in a notification.  

Thanks in advance!  
  • Thanks Dan!  I have no trouble getting the data to local time in JS.  It's more that I store a current date/time value into a QB field via API, then try to use that same time in a notification.  QB takes over from there and uses the UTC time it converted my original local time into, though.  For example, when a user triggers this notification I'm referring to, a timestamp of 3:47PM (EST) gets sent over and is stored in QB as 7:47PM.  The 7:47PM time is what shows up in the notification.  I'm trying to see if there's a way via formula field to adjust to the user's local time for the purpose of the notification since I can't intercept with JS so far as I can tell.  
  • What I'm thinking I'll probably do as a temporary solution is create the timestamp in JS, capture the offset from the UTC time and store it in a separate field from the timestamp itself.  Then I'll create another formula field used to subtract the offset from the timestamp, and that'll be the value I use in the notification.  
  • MCFNeil's avatar
    MCFNeil
    Qrew Captain
    If your clients are in different time zones, I'd recommend identifying the different times zones (via a table) and have the 'adjustment' from UTC be a numeric value, then your time can be a formula of the difference.  Then no matter where they are, it should adjust.

    Not perfect, but an idea.
    • ArchiveUser's avatar
      ArchiveUser
      Qrew Captain
      Thanks Matthew!  I ended up doing something very similar, and it works.  Appreciate the feedback.