AuthHelper.get_current_utc_timestamp returns local time labelled as UTC #139

AuthHelper.get_current_utc_timestamp returns the host's local time read as if it were UTC:

# apimatic_core/utilities/auth_helper.py
@staticmethod
def get_current_utc_timestamp():
    return calendar.timegm(datetime.now().utctimetuple())

datetime.now() is naive local time, and .utctimetuple() does not convert a naive value — it returns
the fields unchanged. calendar.timegm then interprets those fields as UTC, so the result is displaced
from the true epoch by the host's UTC offset.

Why it usually goes unnoticed. OAuth2.fetch_token stamps expiry with this same helper, and
is_token_expired compares against it, so a token the SDK fetched and checks inside one process on one
host is self-consistent.

Where it stops being self-consistent — both are documented, supported paths:

• an expiry the caller computes themselves (from time.time(), or a value another system stored) is
  compared against a clock offset from it
• a token restored via o_auth_token / o_auth_token_provider on a host whose UTC offset differs from
  the one that saved it is judged against the difference between the two

Erring early costs a wasted refresh. Erring late hands an expired token to the API and surfaces as a
401 the client's own bookkeeping said could not happen.

Suggested fix: datetime.now(timezone.utc).timestamp(), or calendar.timegm(datetime.utcnow().utctimetuple()).

Found while grounding the APIMatic skills corpus against generated Python SDKs; the corpus currently
warns readers not to supply expiry themselves because of this.