Convert SAS times to UTC before formatting

[someone1]

Fixes #170

[AtOMiCNebula]

FYI, as-written this will break SAS round-tripping for signatures generated with non-UTC timestamps, just like SAS round-tripping gets broken by dropping timestamp precision as identified in #168.

[zezha-msft]

Hi @someone1, thanks for the PR!

Could you please address the comment from @AtOMiCNebula?

[someone1]

@zezha-msft - I can certainly try!

@AtOMiCNebula - I don't know if I follow as I'm not thoroughly familiar with the process you're describing. Do you mind elaborating a bit? Seeing #169 - I'm inclined to just convert t to t.UTC() inthe formatSASTime function, and use formatSASTime for the snapshot time sh in FormatTimesForSASSigning. Would that be sufficient?

The timestamps seem always to be assumed to be in UTC in the formats - so I'm not sure how you you can generate valid signatures with non-UTC timestamps as you've stated.

[AtOMiCNebula]

@someone1 This library has a bad habit of rewriting components of SASs, which breaks the ability to actually use the SAS. The fix of mine that I referred to earlier was to address an issue where AzCopy was unable to use a SAS produced by Azure itself, because Azure was handing out SASs with timestamps that included a microseconds component. This SDK stripped out the microseconds, and you can't do that, since the signature is invalidated (by design) if you change any of the parts.

My concern is that this change may break round-tripping (though perhaps I came off a bit strong in my earlier statement). The scenario I have in mind is that a string timestamp is parsed into a Time instance that is not UTC, since your change will cause it to be serialized/formatted out to a materially different string than it was before (and thus break the SAS). For instance, from Wikipedia, "2020-06-24T21:13:05-0800". However, upon further reflection, the buggy processing may strip off the time zone identifier in the first place (I haven't tested it), so maybe this whole concern is moot. Either way, please ensure you do not break this in the event that it does presently work. 😄

[mohsha-msft]

Please do the needful :)

[mohsha-msft]

Hey @someone1 ,

Thanks for reaching out !
We are happy to see your contribution.

There are couple of things which I'd like to point out

1. We always merge to dev branch before releasing it to master. So I changed the base to dev branch
2. There is a conflict in merge which will be removed if you do the required changes in either formatSASTimeWithDefaultFormat() function or send UTC time as argument itself.

Also, it'd be nice if you can see whether formatSASTimeWithDefaultFormat() func is getting used some other function call because if that is the case, we need to see if UTC time is required in that function or not?