Would it be simpler to choose a time near noon instead of a time near midnight?
Versus, would choosing a different rather-random epoch number, merely change which timezone suffers the test failure?
@saifalharthi

The problem was daily light shifting. It would've been easier to select another random epoch number but we'll still have some problems with respect to other timezones. So, I forced the return date to be converted and formatted to a timezone that has daylight savings and that should work with any epoch number given.
@randallwhitman

So in other words, no what epoch-number we choose, it will be too close to midnight in some time zone.
Thanks Saif.

Saif - I reviewed TestGeoJsonSerDe looking if it would likely need the same change. It looks like the timezone was addressed in a different manner in that one. Do you think either way is any better or worse than the other?

I will take a look at it

I think the approach in TestGeoJsonSerDe should work out fine. I think since it deals with a default timezone offset it will guarantee a more stable time conversion.

OK, sounds good.

Well, if it works, we can merge now and later think about consistency of timezone handling in that test for EsriJson & GeoJson.