Hello @jkeilson happy to help!

The SDKs all queue up events locally on the client and periodically attempts to upload the unsent events. iOS and Android will batch upload every 30 events or every 30 seconds which ever comes first. So if a user is on your app without internet performing events to Amplitude, the SDKs will queue them locally and try resending them until they are reconnected to the internet.

Now if you mean that the user is on another platform watching videos where Amplitude SDKs are not installed then using the HTTP API is the route to take.

Hope this helps!

@eddie.gaona , we are looking at when a user has lost network connection for an extended period of time. That is great to understand that there is a 30 second buffer for this data.  In cases where a user is on transit and loses connections say for 10-30 minutes we want to retain all of the reporting and be able to pass this along to amplitude on reconnection.  So I assume we’d store all of this information (with date/times of events) locally, and then submit via HTTP API in a batch call?  

https://www.docs.developers.amplitude.com/analytics/apis/batch-event-upload-api/

Thanks!

@eddie.gaona hope you had a happy holidays.  Can you let me know if we should use the batch api above for this use case?  Thanks again

Thanks for circling back @jkeilson. I’ve just forwarded this to the team. Happy holidays to you too! 

Hi @jkeilson ! Hope you had a happy holidays and stepping in for Eddie 

To clarify, the 30 seconds Eddie was referring to is our SDK’s event upload frequency when a user is connected to the internet. If a user is not connected to the internet, the SDKs will queue them locally and try resending them until they are reconnected to the internet. I believe the SDK will store up to 1000 events during offline mode. 

Because of this offline event storage limit though, I would recommend for you to store all of this information (with date/times of events) locally, and then submit via HTTP API in a batch call. You can definitely use Batch API or HTTP API for sending these events! 

Awesome thanks!

Hi @belinda.chiu , sorry one last question!  I noticed when we make server side updates to amplitude they don’t seem to show up in the time zone that our project is configured in.  Do these all default to UTC?  Should we be converted and server side event to UTC?

Thanks!

Jon

Hi @jkeilson ! Our server-side APIs should be using the “time” parameter to determine the time of the event. https://www.docs.developers.amplitude.com/analytics/apis/http-v2-api/?h=http#set-time-values You must send the time parameter in each event as millisecond since epoch which doesn’t consider timezone.

I’m not too clear on your situation but if you’re referring to a different parameter that is not a custom user/event property, then generally yes it is the case that our ingestion systems use UTC as the timezone so it may be best to convert to UTC 

Hi @belinda.chiu , we are passing the date/time ISO as a user property value.  Example below as noted in API docs is sent as a string:

purchase_subscription_date = “2023-01-11 04:00:23 AM”

So it sounds like we should convert this value to UTC time before sending?  

Hi @jkeilson - thanks for clarifying! So sounds like you are sending date/time values to a certain event/user property. You are essentially following https://www.docs.developers.amplitude.com/analytics/apis/http-v2-api/?h=http#set-date-values

If so, then these values that you are sending would just effectively become a string value. 

Can you provide a bit more color on what you mean by “they don’t seem to show up in the time zone that our project is configured in”? Because these values essentially come in as a string, they will appear exactly how you sent the values in. If you wanted them to be reflective of the timezone that your project is configured in, then you will need to send the ISO values as if they were from that timezone. A string value doesn’t get manipulated etc once ingested meaning they won’t get altered based on the timezone set in the project. They will simply appear as they have been sent. 

Hope this helps! 

Hi @belinda.chiu , yes that is correct.  So we sent over the ISO format as string as:

2023-01-18 5:33 PM

But in amplitude this showed up as:

2023-01-18 10:33:26 PM

Do we need to mention timezone with the ISO value maybe?  

@belinda.chiu just checking in so that we can update our API process.  Does this sound like we need to change it to UTC time before updating?  Thanks