How 'CRUD’ful is your API?
If your design, documentation, and paradigm assume the same representation in and out than you have a problem. This is usually solved as a subresource to encapsulate the ‘message’ you want to send.
The other option is to include a redundant property of what essentially is round_floor(now - expiry), which you can update as desired in the front end by saying current ‘expiry + field value’ on the patch or just the value, but you’re going to confuse someone no matter how you decide to do it.
The cause of the problem isn’t datetimes or timezones, its that your design probably doesn’t take into account that resources != objects, and can accept other messages than their normal or default representation (projection).