I don't know what it's going to take, and I had assumed that a big dedicated organization like Let's Encrypt would have squared this situation by now, but you should always, always, always make your certificates expire in the middle of a work day in your local time, never, never, never just exactly 90 days from this instant, which appears to be what happened here.
In RFC 8555 (defining the ACME protocol), when applying for a certificate, although they are optional, you can specify a notAfter time. https://www.rfc-editor.org/rfc/rfc8555.html#section-7.4
Per that section:
> The server MUST return an error if it cannot fulfill the request as specified, and it MUST NOT issue a certificate with contents other than those requested. If the server requires the request to be modified in a certain way, it should indicate the required changes using an appropriate error type and description.
I don't think your beef should be with Let's Encrypt. The timestamps they get are all UTC (or should be UTC), and I don't want them inferring timezone from the IP address of the requestor.
So, that leaves two things:
• Let's Encrypt might blanket-refuse any ACME orders that specify a notAfter time, even if the time difference (from notBefore to notAfter, or from $NOW to notAfter) is within their policies
• ACME clients might not support specifying a particular notAfter time.
I leave it up to you to figure out the two points above, to decide if your ire should go to Let's Encrypt, or to ACME clients.
Probably a good idea to monitor your certificate expiration. You don't want to cut it too close.