Question

Time zones and the API

  • 21 April 2022
  • 5 replies
  • 49 views

Userlevel 2
Badge +3

The copper api uses Unix Epoch times (seconds snice 1970).

Weird, but ok. It really should use rfc 3339 (iso 8601). But, since it doesn’t, it leads to this problem…

it uses unix epoch with respect to some timezone. And this is making integration complex. If its going to be in epoch, it really needs to be in UTC..

 

How can i know what timezone it is with respect to now? there  is no api call to figure that out. and, which sub-timezone. etc. 

 

Is this global to the copper world? to a specific customer?to an object or lead?

 

so for example, when i ceate activity events, they end up in the future since i want to supply UTC. but if i can’t, then i need to know the DST/STD settings as well as the utc offset of the copper server.

 

 


5 replies

Userlevel 6
Badge +5

@donbowman thanks for posting! I looked into this, and the Unix Epoch Time is in UTC. So it is seconds since January 1 1970 00:00:00 UTC.

As for this question:

Is this global to the copper world? to a specific customer?to an object or lead?

If the returned value is a string of numbers then it is in Unix Epoch Time (i.e. UTC). If it returns an actual date format then it’s whatever timezone the owner of the API key has set.

 

Hope that helps :)

 

Note: I’m going to add some more detail to the post title just for housekeeping purposes.

Userlevel 2
Badge +3

so


```
curl -ssL -H X-PW-AccessToken: XXX -H X-PW-Application: developer_api -H X-PW-UserEmail: YYY -H Content-Type: application/json   https://api.copper.com/developer_api/v1/people/ZZZ
```

is going to have a time matching https://www.epoch101.com/ if I change a field?

 

i’m confused about the ‘api key timezone’ bit. I think you are saying that some parts of the api return formatted date, and this gets converted based on some timezone estimation, and some return epoch, which does not.

 

 

Userlevel 2
Badge +3

I guess super concretely, in the below, the event[‘timestamp’] is in iso8601 UTC format. the %s converts it to epoch referenced to +0 utc. But i end up w/ an event in the future by 4 hours when i look in the webui

 

 

def _create_activity(ctx, cul, lead_type, activity_types, category, activity_name, activity_details, event):

event_time = int(dateutil.parser.parse(event['timestamp']).strftime("%s"))

res = ctx.obj.copper.activities.create({
"parent": {
"type": lead_type,
"id": cul['id']
},
"type": {
"category": category,
"id": activity_types[category][activity_name]
},
"details": activity_details,
"activity_date": event_time,
})

For kicks i made one where the time is also in the body in text. Its off by 1 hour. this was done as “User stage changed to MQL @ {event[‘timestamp’]}’ as above parser used.

The event was timestamped 12:17 UTC, or 8:17 eastern(toronto), but mautic represents this as 1:17pm (w/ no timezone shown).

 

Userlevel 6
Badge +5

@donbowman I’m going to connect you with someone on our support team who can help you more directly. They can look more closely at the calls to see if it’s an actual issue or something about how the API works. You’ll receive an email shortly!

I wish I could help you more here, but you’re in better hands with our technical support folks. 🙂

Userlevel 4
Badge +3

Please do report back on this here if possible. I too regularly have issues where activities are logging 1 hour off, no matter what I seem to do across customers. 😅

Reply