fix: use gmdate to format x-amz-date with UTC irrespective of timezone

[yfuruyama]

Issue

Currently the value for x-amz-date is generated from date function, but if user sets a different timezone other than UTC, the generated timestamp has an invalid timestamp.

This causes the following SignatureDoesNotMatch error when authenticating with Workload Identity Federation:

When the timezone is older than UTC:

{"error":"invalid_grant","error_description":"The given AWS signed request is expired."}

When the timezone is later than UTC:

{"error":"invalid_grant","error_description":"Received invalid AWS response of type SignatureDoesNotMatch with error message: Signature not yet current: 20240305T152423Z is still later than 20240305T063924Z (20240305T062424Z + 15 min.)"}

This happens because date('Ymd\THis\Z') produces timezone-aware timestamp, but the suffix is always Z (UTC).

Reproduce

We can easily reproduce this issue just adding date_default_timezone_set('America/Los_Angeles'); to the code.

Also the following code illustrates how date('Ymd\THis\Z') produces invalid timestamp.

$ date
Tue Mar  5 06:37:39 UTC 2024

$ php -a
php > echo date('Ymd\THis\Z');
20240305T063748Z

php > date_default_timezone_set('America/Los_Angeles');

php > echo date('Ymd\THis\Z');
20240304T223756Z

How to fix this

I changed the code to use gmdate instead of date function irrespective of the timezone the user sets.

I locally changed the code and confirmed that this fix works even if a different timezone is set in the code.

[yfuruyama]

@bshaffer Hi Brent, could you review this pull request?

[vishwarajanand]

OP sent me this for a repro: https://screencast.googleplex.com/cast/NTM2MDMzMjAwNzUzODY4OHxhNWE1NTkwOC1iOA

[vishwarajanand]

This change looks good to me.

Per Aws guide on creating signed request, it appears that datetime is required in UTC time in ISO 8601.

I did some testing in my local and confirmed that this change is scoped and looks compatible with existing users php.ini configs.