Docs mention the following about the timestamp field returned by APNs:
"The time, represented in milliseconds since Epoch, at which APNs confirmed the token was no longer valid for the topic. This key is included only when the error in the :status field is 410."
We would like to clarify whether this timestamp is subject to the fuzzy schedule or whether it represent the accurate time of when APNs knew that the token became invalid?
We understand that using 410 for tracking purposes is off label. However we still would like to have the most accurate information in regards to when token became invalid. This will help us debug user issues better in cases when they re-install, uninstall, change permission settings, etc.
You can consider this timestamp to also be effectively fuzzy. The time will usually be when APNs determines that the token is no longer valid, which will be an undeterminable time after the token has become no longer valid on the device.
When the token has been locally flagged as no longer valid will vary depending on why it has become so - is it because the app has unregistered from notifications, app has been deleted, and so on.
After that, APNs will not know about this until a notification is sent to the token, and the device reports the state of the token back. Depending on the app and the use case this could be minutes, or days/weeks.
So, due to how token state is communicated back and forth, the timestamp is not useful for determining exact timing of events, but rather meant to be used for things like helping to manage your token database by showing the earliest date a token would have been valid, for reporting, deleting, merging, etc.
For purposes of determining individual events, the timestamp will be twice removed from the actual event to be a significant indicator.
Argun Tekant / DTS Engineer / Core Technologies
