Expiration date / purchase seems to not be in in same timezone as swift Date()

[NameX44]

Hi,

I've got something weird on my iOS app. I did a StoreKit configuration to test my auto renewable purchase flow.

I buy a 1 month subscription (which expire in 30s). When I call isActiveAutoRenewableSubscription with Date() as parameter it seems that date are not working well, this is what I get :

date : 2020-12-03 20:54:33 +0000
purchaseDate : 2020-12-03 21:54:32 +0000 <--- Seems to be GMT +1
expiration: 2020-12-03 21:55:03 +0000 <--- Seems to be GMT +1

21:54:33 was my current time in France (GMT +1) when I did these logs.

I looked at the expiration date string we received in receipt and it was : 2020-12-03T21:55:03Z.

In a real case, in the moment of the renewing, my user based in France will no longer have active subscriptions detected until the timezone time value has been elapsed.

Have you the same "timezoned" date values on your side ?

Tell me if I'm not clear :)

Thanks for your job.

[zsombornagy]

I just experienced the same problem.

I'm in CET (GMT +1), and when I make a purchase using the local StoreKit configuration, the purchase date of the IAP is set in UTC instead of CET.

So if I buy a subscription now at 11:44 CET, it will then show up as a purchase date of 11:44 UTC, so I have to wait an hour until it will count as an active subscription.

This might have nothing to do with TPInAppReceipt, maybe a bug in Xcode with the StoreKit testing thing, but I can't find anyone complaining about anything similar in any of the forums I checked.

[zsombornagy]

Although this part scares me a little bit:

    func rfc3339date() -> Date?
    {
        let formatter = ISO8601DateFormatter()
        formatter.formatOptions = .withInternetDateTime
        formatter.timeZone = TimeZone(abbreviation: "UTC")

        let date = formatter.date(from: self)
        return date
    }

[tikhop]

Hi @NameX44,

Thanks for bringing this up. Gonna try to make a purchase and check what's the default timezone is used in the local receipt. I thought it's must always be GMT0.

@zsombornagy Regarding that piece of code you shared I can't say anything for now, but there definitely was a reason to convert it to UTC. Maybe, since Date() returns time in UTC, I decided to convert it to UTC right away. It was a long time ago.

[NameX44]

Hi @tikhop @zsombornagy ,

it seems to only happen with StoreKit configuration file receipt. I tried in sandbox and no problem everything works fine.

Maybe it's a bug in Apple side ?

[tikhop]

Hi @NameX44,

Appreciate your efforts in trying to figure it out. I have only tried in sandbox and it works well. Can’t say anything about StoreKit configuration tho, but I’m going to try it out in the short future.

[chrisvanbuskirk]

I noticed some date issues for purchases when using store kit testing. There was no problem however in the sandbox. Pointing fingers at Apple.

[Kondamon]

I have experienced the same issue in StoreKitTest.

As a work around I do a manual conversion:

/// Returns the corrected date in UTC, since the receiptDateString has the wrong timeZone (Failure of StoreKitTest??)
func getCorrectedDateFromLocalTime(from receiptDateString: String) -> Date {
    let diffHours = TimeZone.current.secondsFromGMT() / 3600
    let timeZoneCorrection = "+0" + String(diffHours) + ":00"
    
    let adaptedUTCString = String(receiptDateString.dropLast()) + timeZoneCorrection
    
    let dateFormatter = DateFormatter()
    dateFormatter.locale = Locale(identifier: "en_US_POSIX") // set locale to reliable US_POSIX
    dateFormatter.dateFormat = "yyyy-MM-dd'T'HH:mm:ssZ"
    
    return dateFormatter.date(from: adaptedUTCString)!
}

[tikhop]

Hi @Kondamon, thanks for posting your workaround. I still haven't got a chance to play around with StoreKitTest, but I will definitely do it. So far, the legacy way, when you test on device without StoreKitTest works well and, the most important, it works in production. Nevertheless, I agree, it must work with StoreKitTest as well.

[NameX44]

Hi,

it think that I've a problem which seems to be related to this one on production build. Does someone know a way to get the receipt from a production app and analyse data in it ?

Thanks,

[tikhop]

Hi @NameX44,

I think the only way is to have an api endpoint and when the app starts you can call that endpoint with a receipt (base64 string) attached.

[tikhop]

Hi @NameX44,

Have you got a chance to debug the receipt from a production build?

[NameX44]

Hi @tikhop,

Unfortunately no, I sent a TSI, they asked me to create a feedback: https://feedbackassistant.apple.com/feedback/8975589.

[tikhop]

Got it — hope they will provide a valuable feedback.

[NameX44]

Forgot to tell you that I got a response on the feedback and it seems to be fixed in the current beta. We will see on release :)

[tikhop]

Awesome, thank you!

[motocodeltd]

for what it's worth, storekittest started generating receipts to me with purchaseTime in BST (UTC+1) since daylight savings kicked in, which as far as I can tell is incorrect - purchaseTime should be in UTC. the TPInAppReceipt code is correct. In fact, I get a string like "2022-03-30T18:19:41Z". Z means UTC but that was generated by one of my tests and that time was actually UTC+1 not UTC. Seems like (another) bug in storekittest

[tikhop]

@motocodeltd, @NameX44, @zsombornagy Seems like the issue has been fixed and nobody is complaining anymore — I'm closing it.