Enhanced the UnixDateTimeConverter to...

[rsnet]

Enhanced the UnixDateTimeConverter to handle values that are milliseconds since Unix Epoch, in addition to normal values (seconds since Unix Epoch).

Why?

In #3157 there are multiple reports (stack traces) of the UnixDateTimeConverter being responsible for incorrect values being put into the method System.DateTime.AddSeconds(Double value).

The root cause is Stripe API responses sometimes return long values that are the milliseconds since Unix Epoch, instead of the seconds since Unix Epoch (typical). I was able to determine this by debugging through the code during a request in a Sandbox - I found that some values (in the responses from the Stripe API) that were being converted by the UnixDateTimeConverter were larger than 253402300799. I noted some of these values, and converted these long values using DateTimeOffset.FromUnixTimeMilliseconds(long milliseconds), and found that the values converted nicely to dates very close to my requests (or data in my requests).

In the few requests that I debugged through, most Unix Epoch values are seconds; unfortunately one was milliseconds.

What?

This PR enhances the UnixDateTimeConverter, so that it can automatically handle both types of Unix Epoch values that the Stripe API returns:

• seconds since Unix Epoch
• milliseconds since Unix Epoch

It uses a the value 253402300799 as the maximum allowable value for seconds since Unix Epoch, and presumes all values greater than this are milliseconds since Unix Epoch.

Two new unit tests were created for the UnixDateTimeConverter to verify it can handle both cases correctly.

See Also

See my post on Issue 3157 showing the stack trace when the UnixDateTimeConverter.cs attempts to convert values that are milliseconds since Unix Epoch.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[jar-stripe]

Hi @rsnet thank you for submitting this PR! I recall this being an issue but I thought we had previously addressed it; let me do a bit a research and then I'll review your PR. Thanks!

[prathmesh-stripe]

@rsnet Can you please sign the CLA agreement in order to accept your PR

[rsnet]

@prathmesh-stripe, I have tried to sign the CLA multiple times. On the second screen, it never presents a button to move forward (like the first screen). SAP needs to fix it.

[prathmesh-stripe]

@rsnet Can you share a video screenshare of what you are seeing? I tried signing it myself, I had to authorize the cla-assistant app with my Github account and then fill in Country at the bottom before clicking I agree. It took me another screen that redirected me back to Github.

[prathmesh-stripe]

We ended up releasing a fix for this in: https://github.com/stripe/stripe-dotnet/releases/tag/v50.0.0