{"id":30389,"date":"2020-10-08T16:16:19","date_gmt":"2020-10-08T20:16:19","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=30389"},"modified":"2023-05-29T10:16:40","modified_gmt":"2023-05-29T14:16:40","slug":"date-format-change-in-app-store-receipts","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/10\/08\/date-format-change-in-app-store-receipts\/","title":{"rendered":"Date Format Change in App Store Receipts"},"content":{"rendered":"

Frank Illenberger<\/a>:<\/p>\n

After some sweat and tears we have found the reason for the installation failures in the Mac App Store:\nAt some point in the last weeks, Apple has changed the format of the date values in its ASN.1 receipt files.<\/p>

They used to look like “2020-10-03T07:12:34Z”. Now they added millisceonds like in “2020-10-03T07:12:34.567Z”. Apple’s specification only states that dates follow RFC 3339, which does not specify if there should be milliseconds or not.<\/p>

[…]<\/p>

To make it even harder, Apple still sends out receipts containing dates WITHOUT milliseconds if an app has been originally bought before October.<\/p><\/blockquote>\n\n

Daniel Jalkut<\/a>:<\/p>\n

\n

More on this: as far as I can tell the documented IAP dates are still returning dates that don’t have milliseconds. I don’t think there is a documented<\/em> date field for Mac App Store receipts for the main app, as installed in the app binary.<\/p>\n<\/blockquote>\n

These are the documented fields for local (on a Mac) receipt validation<\/a>.<\/p>\n

For server side receipt validation, there are host of other fields<\/a>, including one that exposes the original purchase date in timestamp format.<\/p><\/blockquote>\n\n

Rosyna Keller<\/a>:<\/p>\n

The dates on the receipt documentation pages all mention they’re in ISO 8601, so you’d want to use that data formatter to read them instead of specifying an entirely manual, hand-crafted format string.<\/p><\/blockquote>\n\n

Hilariously, the documentation only promises that the date format will be “similar to the ISO 8601.”<\/p>\n\n

Pádraig Kennedy<\/a>:<\/p>\n

A base ISO8601DateFormatter will parse the non-ms version only. To avoid this issue, devs would have to make two date parsers and try them one after another.<\/p><\/blockquote>\n\n

Daniel Jalkut<\/a>:<\/p>\n

If anybody thinks ISO8601 datetime strings are a well-defined format, here’s the code in \n@MarsEdit\n that handles ISO8601 dates from various blogging platforms.<\/p><\/blockquote>\n\n

Previously:<\/p>\n