feature: recording expiration to respect timezones

Description

The startedDateTime is a timestamp but does not include timezone information. This could lead to potential problems with expiration calculation.

Example situation:

• User A records a network call in GMT -05:00
• expiresIn is set to e.g 3 days
• User B replays a network call in GMT +7:00, 2.5 days later

The request will expire since startedDateTime will be converted to the local timezone.

Another example would be running code with Polly on CI which hosts servers on a different timezone than your machine. This way you could get inconsistent results compared to localhost.

Suggested solution

It would be good to save the timezone information into the startedDateTime in the har file (or any other persister format), so it can be parsed together with the timestamp & current time converted to the timezone of the recording for comparison to get consistent results regardless of the location.

[TheMelter]

@jasonmit @sankaritan

Please correct me if I’m wrong, but it looks like the request timestamp - startedDateTime - is already being saved as UTC using new Date().toISOString(). Then in is-expired.js, this recordedOn timestamp with expiresIn is converted to local timezone and compared against local time. Happy to tackle the issue, but need more clarification.

[jasonmit]

Closing as it appears to have gone stale.

If it’s still an issue in the future, please open a new issue instead of responding on closed issue.