Skip to main content
Solved

Incorrect date format for processed_time field from the Export API

  • May 31, 2022
  • 1 reply
  • 698 views

Is anyone else seeing incorrectly formatted timestamps from the Export API? This is causing an error for a script I have that calls that API.

The issue I’m seeing is that events roughly with a processed_time value that’s between 2022:05:27 01:02:50.047099 and 2022:05:27 11:28:48.569078 do not have that field in ISO-8601 format. An example of the format I would expect is 2022-05-27T00:27:49.773Z.

From the Export API documentation, it’s stated that that field should be an “ISO-8601 formatted timestamp.” which means the year, month, and day should be separated by a hyphen.

 

Any help from the Amplitude support team would be much appreciated.

 

API docs for response data, copied here:

{

"server_received_time": UTC ISO-8601 formatted timestamp,

"app": int,

"device_carrier": string,

"$schema":int,

"city": string,

"user_id": string,

"uuid": UUID,

"event_time": UTC ISO-8601 formatted timestamp,

"platform": string,

"os_version": string,

"amplitude_id": long,

"processed_time": UTC ISO-8601 formatted timestamp,

"user_creation_time": UTC ISO-8601 formatted timestamp,

"version_name": string,

"ip_address": string,

"paying": boolean,

"dma": string,

"group_properties": dict,

"user_properties": dict,

"client_upload_time": UTC ISO-8601 formatted timestamp,

"$insert_id": string,

"event_type": string,

"library":string,

"amplitude_attribution_ids": string,

"device_type": string,

"device_manufacturer": string,

"start_version": string,

"location_lng": float,

"server_upload_time": UTC ISO-8601 formatted timestamp,

"event_id": int,

"location_lat": float,

"os_name": string,

"amplitude_event_type": string,

"device_brand": string,

"groups": dict,

"event_properties": dict,

"data": dict,

"device_id": string,

"language": string,

"device_model": string,

"country": string,

"region": string,

"is_attribution_event": bool,

"adid": string,

"session_id": long,

"device_family": string,

"sample_rate": null,

"idfa": string,

"client_event_time": UTC ISO-8601 formatted timestamp,

}

Best answer by belinda.chiu

Hi @angela_compiler ! Welcome to the Amplitude Community 👋 Thank you for letting me know this is a duplicate post. For alignment purposes, I’ll also go ahead and share the information I shared with you here:

Our sincerest apologies for the disruption that the changed date format has caused. The Engineering acknowledged this bug last Friday and the data going forward since Friday 7:30am PT is now fixed. Unfortunately none of the existing broken/bad data can be fixed in the short term. We sincerely apologize for breaking your pipelines in unexpected ways or for any other issues that this may have caused you. 
 
Please let me know if you have any questions regarding this, our Engineering team will be available to address any concerns you may have. Apologies again for the inconvenience! 

View original
Did this topic help you find an answer to your question?

1 reply

belinda.chiu
Team Member
Forum|alt.badge.img+8
  • Amplitude Support
  • 190 replies
  • Answer
  • May 31, 2022

Hi @angela_compiler ! Welcome to the Amplitude Community 👋 Thank you for letting me know this is a duplicate post. For alignment purposes, I’ll also go ahead and share the information I shared with you here:

Our sincerest apologies for the disruption that the changed date format has caused. The Engineering acknowledged this bug last Friday and the data going forward since Friday 7:30am PT is now fixed. Unfortunately none of the existing broken/bad data can be fixed in the short term. We sincerely apologize for breaking your pipelines in unexpected ways or for any other issues that this may have caused you. 
 
Please let me know if you have any questions regarding this, our Engineering team will be available to address any concerns you may have. Apologies again for the inconvenience! 


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings