Update the commerce_payment_method.expires field to store only unsigned values.

Ran into this error with the stripe module as well. Seems some kind of validation is in order. Does the Credit Card Industry have a standard for how far in the future the expiration date can be? If so could some kind of validation to check against that be added? I'm sure this isn't that easy, just thinking out loud.

Also experienced this in testing. I think we should just make a validation for this to avoid the fatal error (have the exp date fail validation instead of trigger the error)

Then when 2038+ is supported we can remove the validation.

Marking this as a bug because a fatal error is a user interface problem.

I just came accross this testing Stripe.
To prevent friction from wsod (customer typo), and since I don't think we can add validation to Stripe fields, I ended up creating a lame patch that does

if ($timestamp > 2145830400) {
  $timestamp = 2145830400;
}

within setExpiresTime method in the PaymentMethod class.

I'll stick to that until #2885413: Timestamp field items are affected by 2038 bug lands.
Also related: https://www.drupal.org/node/3227494

For the benefit of others landing here - I've today had this happen in a production site. Customer has a debit card with expiry of October 2039 - so these cards are out there... The card payment succeeded with Stripe - then choked in Commerce. Will have to manually place order.

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column 'expires' at row 1: INSERT INTO "commerce_payment_method"

Why don't we just convert this particular field to unsigned? We don't need to support expiration dates before the UNIX epoch began. 🤷‍♂️

@rszrama: Because we use a "timestamp" field which defines the following schema:

  /**
   * {@inheritdoc}
   */
  public static function schema(FieldStorageDefinitionInterface $field_definition) {
    return [
      'columns' => [
        'value' => [
          'type' => 'int',
        ],
      ],
    ];
  }

As opposed to a regular "integer" which exposes the following schema:

  /**
   * {@inheritdoc}
   */
  public static function schema(FieldStorageDefinitionInterface $field_definition) {
    return [
      'columns' => [
        'value' => [
          'type' => 'int',
          // Expose the 'unsigned' setting in the field item schema.
          'unsigned' => $field_definition->getSetting('unsigned'),
          // Expose the 'size' setting in the field item schema. For instance,
          // supply 'big' as a value to produce a 'bigint' type.
          'size' => $field_definition->getSetting('size'),
        ],
      ],
    ];
  }

It's possible for integer fields to mark the field as "unsigned" from the field definition which is not possible for Timestamp fields.

I wonder if we could fix this from a storage schema class in the meantime, until Drupal core supports setting the unsigned boolean from the field definition.

Bumping the priority, will try fixing this today.

Tempted to go ahead and merge this as I tested this on a new install and on an existing install successfully.
However, would be great if somebody else could RTBC the change.

Went ahead and merged the MR.