I’m using the endpoint for creating activities and have a question about the time of the activity. It is stated that the time should be in UTC, which makes sense in lots of cases. However, it makes things complicated when it comes to passing a time entered through user input.
Unless the user is in UTC, I would have to calculate the UTC time before creating the activity through the API. How would I do that in the best way? I figure I can use for example GET /users/{id} to get the user’s time zone settings. That info I get is just an offset though and it doesn’t seem to care about daylight saving time and similar (yeah, time zones and everything related to it is in general a mess for every developer…).
Best would be if I could create the activity having a flag set called “local_time”, but I guess that’s not available?
Please let me know if there’s a simple solution to this issue.
You shouldn’t have to focus on getting a User’s timezone (except for when looking at responses). Adding activity times will convert to that User’s timezone, so you only need to make sure that any times you’re adding are in UTC - in this way, I guess you would need to know the User’s timezone so you would know what to change it to for UTC, but this is dependent on how the activities are being added.
“…you only need to make sure that any times you’re adding are in UTC”
Exactly, and this is my problem.
To give an example - let’s say I create a simple app in which I, as a user of Pipedrive, can create activities (very similar to Pipedrive’s own activity creator). I would of course enter my local time in the app when adding activities, just as I would in Pipedrive’s activity creator. If the app would just take the user input and pass it to the API though, the resulting time would be wrong as the API uses UTC. This means my app needs to have info about the user’s time zone setting (and since this is based on a Pipdrive user, the app needs the time zone setting fetched from Pipedrive), then calculate the offset taking daylight saving time into account. I would say it’s quite complicated.
Hi. Whats your usecase?
If you want to create activities for specific time (lets say new year in Moscow) for users in different timezones, you don’t need users’ timezone, just use UTC
But if your logic depends on user’s timezone, for example create activity for 8am, depending on where user is located, then yes, you should use timezone_name or timezone_offset to set user-varying time
My use case is similar to your second example - it’s dependant on the user’s own timezone.
And yes, the solution you suggest is the only solution I can think of too and I was hoping for something easier.
There’s no way of telling the API that I’m providing a time in the user’s local time and by doing so the conversion is handled on Pipedrive side? I mean since you already have that logic on your side, it would be nice to avoid performing the same calculation on my side.
Yes, you’re right. I’ll suggest these “relative user’s time during entity creation” changes internally to teams who deal with this API, but I can’t guarantee it will be done or if it will be done fast enough for your case
This gave me big headaches too. It’s OK when you have a datetime field. But when it’s just a date field, then it get’s tricky converting it to a utc date time… do you use midnight, or the current time, so then what do you do when you have to convert it back.If you are adding days to a date, the difference between UTC and local time also has an impact on the result. UTC time might be yesterday, local time is today, do I use midnight local time to be the change of day or do I use midnight UTC time!
It’s also tricky in the activities because the date and time are separate fields, so you have to join them together, convert them to utc, then split them again.
In looking at this I’ve realised I still have some work to do when mapping date fields to/from Pipedrive and QuoteWerks!
I understand why Pipedrive stores dates like this, but it does make it more interesting when you actually start to try and use the dates/times.