RFC: Change type of timestamp fields from `Long` to one of the `java.time` types

[ob-stripe]

trafficstars

Hi stripe-java users,

As you most likely know, Stripe's API uses Unix timestamps to represent moments in time, such as the created attribute on most API resources, the trial_end parameter when creating a subscription, etc.

Today, these fields are represented as java.lang.Long in the stripe-java library, and it is up to users to convert these values into the appropriate time representation.

We think we can provide a better default behavior and are considering changing the type of these fields to one of the native time types available in Java 8. To this end, we would like to get feedback from stripe-java users (i.e. you!).

To be clear: this would be a backwards-incompatible change, as it would change the type of all timestamp fields from java.lang.Long to one of the java.time types.

1. Would you be in favor of such a change?

2. Which type do you feel would you be most appropriate to represent timestamps? We're leaning towards java.time.ZonedDateTime (where the zone would always be UTC/Greenwich), but maybe java.time.Instant or another type would be more convenient.

[orangecoding]

I'm not sure tbh what the benefit is. I think the client should leave it up to the user what to do with the timestamps.

For instance, we have situations, where we read something from stripe and directly pipe certain values like start/end it into a stream towards the frontend. If this would be a native Java obj, I'd have to re-format it to a unix ts.

[totof3110]

ZonedDateTime would make sense if the timezone was not constant or was carrying some meaningful information. If it's always going to be UTC then Instant seems more appropriate.

BTW, currently we usually convert the timestamp to Instant in our code like:

Instant created = Instant.ofEpochSecond(stripeObject.getCreated());

[richardm-stripe]

Hello, it's been awhile!

Given the mixed feedback here, it's unlikely we'll move away from Long for any of the existing APIs. We may introduce Instant or ZonedDateTime for future APIs, if appropriate.