What is the list of timezone IDs?

I am well aware of the “core concepts” and I do know that dates set via the API (unlike when done through the UI) are stored in UTC. This is all well until one starts using automatic customer e-mail generation where a custom date field is imported into the generated e-mail in a UTC time. Unless the customer lives in a UTC timezone, this is obviously useless.

However, the API seems to have some timezones implemented:

"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx": "15:30:00",
"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_until": "16:00:00",
"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_timezone_id": 327,

My question is - what does the ID 327 stand for and could we possibly get a list of these timezones, so that we can set them accordingly? So that we can use other services of Pipedrive, like the automatic e-mail for example.

Thanks a lot!

Hi Michal,

What endpoint are you using here?

This was a simple GET on /deals.

I see. I missed that you were using a Time field before.
The timezones that they apply to are connected to a private endpoint at the moment (making them kind of pointless for you). I’ll see if I can create a list, but I may not be able to since the IDs could change (since they’re private)

OK thank you, that would be helpful.

In case you are unable to provide that, what is the recommended approach? To not use date and time fields when working via API? Shouldn’t it be in the documentation that connected services, such as pipedrive’s e-mail templates will break when custom fields with date values cannot be interpreted in the correct timezone?

Example:

  1. Client makes an order that requires personal meeting. Our e-commerce backend creates a deal, sets a date and time (in UTC, as suggested in core concepts) for the meeting.
  2. Pipedrive sends an e-mail template with prefilled data from the deal. The time is sent to the client in UTC.

If the backend could send the ID of the timezone that would probably solve everybody lots of headaches?

It’s not ideal, but you can use the GET /users/{id} endpoint to find out the timezone for each User. This would be the timezone they see whenever adding information in-app to time/date Fields.

While this is a solution for users of Pipedrive, I don’t think this solves the problem I outlined above.

Example:

  1. Our e-commerce backend receives an order that requires an appointment in person with the client. A client is represented in Pipedrive as a person (available for example under GET /persons).
  2. If we stick to the core concepts, this date will be saved in UTC. But such approach breaks automatically generated e-mails in Pipedrive and any automatically generated calendar invites. We need to tell Pipedrive which timezone to generate these values in.

The client is not a user. Or am I missing something and GET /persons contains timezone ID as well based on their address?

I suppose silence here means - “It does not work, correct.”

Is this issue internally tracked? Is there any rough timeline for assigning this issue to a mission for internal team to tackle?

But most importantly - what should we do to mitigate this shortcoming before it gets resolved in the API?

@David any update on the roadmap for supporting timezones so that dates and times work when API is used?

Unfortunately no. They’re still used only internally and subject to change, hence the inability to release them publicly.

I am talking with the team to have a better solution (using acronyms instead of IDs), but no ETA.

1 Like