expires_date format

I'm sending a sandbox receipt to https://sandbox.itunes.apple.com/verifyReceipt and the response I'm getting back has the expires_date in milliseconds.


My request is a POST with body:


{
  "receipt-data": "...",
  "exclude-old-transactions": true,
  "password": "..."
}


And the response includes:


"receipt": {
...
  "expires_date_formatted":"2019-05-08 18:37:12 Etc/GMT", 
  "expires_date_formatted_pst":"2019-05-08 11:37:12 America/Los_Angeles", 
  "expires_date":"1557340632000", 
  "transaction_id":"1000000526017377", 
  "is_in_billing_retry_period":"0"
...
}


The expires_date property is documented as RFC 3339 (here).


What should I do for parsing this? I've seen other receipts that have a proper RFC 3339 date so I don't know if I need to be able to handle both or if this is a temporary problem?


Thanks

-- Steve

Replies

At the very least it’s a documentation bug - the description also says it’s in milliseconds since the epoch as well as RFC 3339. Seems like a copy and paste error somewhere.


Have you seen the other receipts with expires_date, or was it actually expiration_date?

I'm not at the point of getting receipts from the live environment, but I've seen examples that show the expires_date in a different format. For example, here and here.


These posts show a receipt with an expires_date field in this format:


"expires_date":"2016-12-31 17:05:24 Etc/GMT",


I'm lookiing for guidance on how to parse this field. Try as milliseconds and if that fails, try as this format, and if that fails try RFC 3339? I don't want to find out when I deploy the live app that the date is coming back in a format I was unable to test.


Thanks

So, no advice on this?


The documentation is incorrect, and as noted on the documentation pages, is no longer being updated. Is there a newer endpoint we can use or some other way of verifying receipts?