Add unit tests for util classes (DateTimeUtils, TimeZoneUtils)

[vbauer]

No description provided.

[azurecla]

Hi @vbauer, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.

TTYL, AZPRBOT;

[serious6]

looks good 👍

[vboctor]

Looks good. Would be nice to do some non-UTC tests and potentially support case-insensitive lookups in the timezone hashmap.

[vbauer]

It looks like TimeZone class doesn't support case-insensitive identifiers (see TimeZone.getTimeZone) and method TimeZoneUtils.getMicrosoftTimeZoneName works with it.

I'll add some positive and negative tests for lookup.

[vbauer]

PR was updated.

[vboctor]

Does it make sense to keep the ones that are out of date? When are these useful?

[vbauer]

@vboctor I don't know (it isn't my code), I've just formatted length of this line (it was too long).

[vbauer]

Thx for CR, PR was updated.

[vbauer]

I found that it depends on env. setup. Is it OK?

[serious6]

shouldnt this be a little against design of unit-test to assert one or another?

[vbauer]

Yes, I also don't like this, but as I wrote method TimeZone.getTimeZone depends on tzdata (in JVM):

• If you have timezone "Antarctica/Troll" in tzdata, than you'll get "null".
• If you haven't it, than you'll have "UTC".

Do you have any idea how to improve it?

[serious6]

@vbauer wouldnt it be a solution to the problem if we just pick a timezone that def. will be in tzdata? Or is this just random? And why do you think this timezone will not be referenced on travis? If this can cause problems please add a comment to the test. This could ref. to tzdata-versions for instance.

[vbauer]

PR was update. I think it will be enough to have test with "Africa/Abidjan" timezone.

[serious6]

@vbauer thanks for your contribution