Comment 2 for bug 838525

Hi Bill,

We reported a similar (if not exact same) issue to our support vendor in January 2011. This was the response, in hopes it helps to resolve this bug.

"In short, older versions of Evergreen are flawed, but the flaws weren't made apparent until we started getting more consortia with branches spread across timezones. Trying to backport these fixes (to 1.6) amounts to development work; a good bit of it.

A simple example of a date handling bug:
Database sends a timestamp over the internet as a textual string:
"2011-01-01 00:00:00-0500"

Staff client naively displays the first 10 characters:
"2011-01-01"

This can only be correct if the staff client happens to be in the -0500 timezone.

If for some reason, the database sends this equivalent timestamp:
"2010-12-31 23:00:00-0600"

Then the client will incorrectly show:
"2010-12-31"

Newer versions of the code do not do this."

It seems, however, that the "newer versions" haven't totally resolved the problem. We're on 2.0.4 and we find we still have to make sure birth dates don't get "too close" to midnight. An issue came up last week with a new migration where 'dob' was loaded simply as '2011-01-01' rather than '2011-01-01 11:00:00-5' and since we have libraries in 2 time zones in Indiana different locations were seeing a different DOB.