Add decode timezone support

[guyzyl]

Added timezone support to options dictionary.
The change is needed since the expiry of the tokens are validated against the machines local timezone, this new option enables explicitly choosing and setting the timezone used for decoding and validations.
I made to sure to document the new option + wrote a test for it.
This solves issue #487 .

[jpadilla]

@auvipy we need to think through this one. what does the spec say? what are other libraries doing? not sure this is the way forward.

[auvipy]

yup, that's why not merging but waiting for your thoughts.

[guyzyl]

@auvipy would it be possible to merge it now?

[jpadilla]

@guyzyl I think this shouldn't be a thing that can be specified, it should always be UTC according to the spec: https://tools.ietf.org/html/rfc7519

NumericDate
A JSON numeric value representing the number of seconds from
1970-01-01T00:00:00Z UTC until the specified UTC date/time,
ignoring leap seconds. This is equivalent to the IEEE Std 1003.1,
2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in
which each day is accounted for by exactly 86400 seconds, other
than that non-integer values can be represented. See RFC 3339
[RFC3339] for details regarding date/times in general and UTC in
particular.

Also, can this be done without introducing a dependency on pytz?

[guyzyl]

👍🏼

[guyzyl]

If it shouldn't be specified then it's possible to close this PR + ticket.
Regarding pytz, it's possible to drop it as a dependency, will do that if we decide we want to merge the feature.

[guyzyl]

@jpadilla Should I close the PR or fix it?

[guyzyl]

@jpadilla Should I fix it (as per you comment), or close the PR?

[jpadilla]

@guyzyl sorry for the delay. i don't think this is a change/feature we should introduce.

[guyzyl]

@jpadilla no worries, makes total sense.