TimeWindow.writeToXmlUnscopedDatesOnly should have UTC set on formatter

[cfraser]

This pull request resolves an issue where the TimeWindow can be incorrectly shifted because it is serialized to "yyyy-MM-dd'T'00:00:00" in the timezone of the server and deserialized in UTC. This occurs for two reasons:

• SimpleDateFormat uses the timezone of the system when a timezone has not been explicitly set
• the Date is serialized without a timezone value and a fixed time of 0:00:00, and then deserialized by EwsServiceXmlReader.readElementValueAsUnbiasedDateTimeScopedToServiceTimeZone() which explicitly sets 'UTC' as the timezone.

Additionally, treating a date with no timezone as UTC also conforms to Table 2 in the Handling Timezones in EWS section of Time zones and EWS in Exchange.

• set the timezone to UTC on the formatter in writeToXmlUnscopedDatesOnly
• resolves Availability Service timewindow shifted by timezone #241

[azurecla]

Hi @cfraser, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.azure.com.

TTYL, AZPRBOT;

[cfraser]

I'm investigating if I need legal sign-off for the CLA.

[serious6]

In my opinion the whole TimeWindow class should be replaced with joda#period. Any comments?

[cfraser]

Hrm, I'm not sure that TimeWindow and joda#period overlap neatly.

I think we could back the TimeWindow with a joda period that functions on 24 hour blocks. I agree that the use of epochs is misleading, so it would be nice to provide an API that self documents the full day constraint that TimeWindow enforces. Of course that's a breaking change, so it's something we could put up for consideration in 3.x.x.

We also need to consider that TimeWindow has some specific code for serializing the class to xml so we likely can't completely replace it with joda.

[serious6]

this PR should be referenced against the 2.0.x branch as this will be a minor change.

[cfraser]

Talked to legal, now I'm waiting on my senior director to sign then we should be good.

[cfraser]

Should I open another PR to the 2.0.x branch once this merges into master?

[serious6]

can you also add some explanation on why we need this change in detail?

[cfraser]

I'll add it to the PR description shortly.

[cfraser]

@serious6 I've updated the PR description to explain my reasoning for the pull request. Please let me know if you need any further details, or have any concerns.

[serious6]

@cfraser cla still needs to be signed.

[cfraser]

@serious6 I've signed it and I'm waiting on my senior manager to sign. I just sent him a follow up email to try and move things along.

[azurecla]

@cfraser, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.

Thanks, AZPRBOT;

[serious6]

@cfraser thanks for your contribution.